软体开发文档详细资料大全

1. 《功能要求》 -- 来源于客户要求和市场调查，是软件开发中最早期的一个环节。客户提出一个模糊的功能概念，或者要求解决一个实际问题，或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书，把他们的要求全部列表书写在文档中，必要时加以图表解说。这份文档是需求分析的基础。

2. 《投标方案》 -- 根据用户的功能要求，经过与招标方沟通和确认，技术人员开始书写《投标方案》，方案书一般包括以下几个重要的章节： 前言 -- 项目背景、公司背景和业务、技术人员结构、公司的成功案例介绍等。 需求分析 -- 项目要求、软件结构、功能列表、功能描述、注意事项等。 技术方案 -- 总体要求和指导思想、技术解决方案、软件开发平台、网络结构体系等。 项目管理 -- 描述公司的软件开发流程、工程实施服务、组织和人员分工、开发进度控制、软件质量保证、项目验收和人员培训、软件资料文档等。 技术支持 -- 公司的技术支持和服务介绍、服务宗旨和目标、服务级别和响应时间、技术服务区域、技术服务期限、授权用户联系人等。 系统报价 -- 软、硬件平台报价列表、软件开发费用、系统维护费用等。 项目进度 -- 整个项目的进度计划，包括签署合同、项目启动、需求分析、系统分析、程序开发、测试维护、系统集成、用户验收、用户培训等步骤的时间规划。

3. 《需求分析》 -- 包括产品概述、主要概念、操作流程、功能列表和解说、注意事项、系统环境等。以《功能要求》为基础，进行详细的功能分析 ( 包括客户提出的要求和根据开发经验建议的功能 ) ，列出本产品是什么，有什么特殊的概念，包括哪些功能分类，需要具备什么功能，该功能的操作如何，实现的时候该注意什么细节，客户有什么要求，系统运行环境的要求等。这里的功能描述跟以后的使用手册是一致的。

4. 《技术分析》 -- 包括技术选型、技术比较、开发人员、关键技术问题的解决、技术风险、技术升级方向、技术方案评价，竞争对手技术分析等。以《需求分析》为基础，进行详细的技术分析 ( 产品的性能和实现方法 ) ，列出本项目需要使用什么技术方案，为什么，有哪些技术问题要解决 ，估计开发期间会碰到什么困难，技术方案以后如何升级，对本项目的技术有什么评价等。

5. 《系统分析》 -- 包括功能实现、模块组成、功能流程图、函数接口、数据字典、软件开发需要考虑的各种问题等。以《需求分析》为基础，进行详细的系统分析 ( 产品的开发和实现方法 ) ，估计开发期间需要把什么问题说明白，程序员根据《系统分析》，开始在项目主管的带领下进行编码。

6. 《数据库文档》 -- 包括数据库名称、表名、字段名、字段类型、字段说明、备注、字段数值计算公式等。以《系统分析》为基础，进行详细的数据库设计。必要时可以用图表解说，特别是关系数据库。

7. 《功能函数文档》 -- 包括变量名、变量初值、功能，函数名，参数，如何调用、备注、注意事项等。以《系统分析》为基础，进行详细的说明，列出哪个功能涉及多少个函数，以便以后程序员修改、接手和扩展。

8. 《界面文档》 -- 包括软件外观、界面素材、编辑工具、文件名、菜单、按钮和其它界面部件的要求，这里与软件完成后的运行界面是一致的。

9. 《编译手册》 -- 包括服务器编译环境、操作系统、编译工具、 GNU 的 C++ 编译器版本信息、目录说明、程序生成、源程序文件列表、 Makefile 配置及其相关程序的对应关系列表。客户端的编译过程、编译结果、编译示例、编译环境、操作系统、编译工具、源文件列表和制作安装程序的过程。

10. 《 QA 文档》 -- 包括产品简介、产品原理、产品功能列表、功能描述、功能流程、执行结果、数据库结构、测试要求等，提供给软件测试人员使用。

11. 《项目总结》 -- 包括项目简介、项目参与人员和开发时间、项目风险管理过程、项目功能列表、项目结构特点、技术特点、对项目的升级建议、对以后的项目的建议、人员素质情况等。 1. 《产品简介》 -- 包括公司背景、产品概念、适用范围、产品功能、功能特点、运行要求和公司联系地址。

2. 《产品演示》 -- 包括公司简介、产品背景、产品描述、产品特点、产品作用、适用范围、使用分析、功能模块、解决问题、合作伙伴、成功案例等。一般用 Power point 或者 VCD 录制软件实现。

3. 《疑问解答》 -- 列出用户关心的问题和处理方法。用于解答软件的操作功能和解决用户的疑难问题。

4. 《功能介绍》 -- 以《需求分析》为书写基础，包括软件介绍、软件结构、功能列表、功能描述和公司联系地址。

5. 《技术白皮书》 -- 以《技术分析》为书写基础，包括功能实现、技术选型、关键技术问题的解决、技术方案特点、技术升级方向等。

6. 《评测报告》 -- 第三方权威评测报告。包括评测目的、评测范围、评测环境、评测内容、实测数据、性能表现、结果分析和评测总结等。

7. 《安装手册》 -- 包括系统环境、运行平台、产品安装过程、初始环境设置、安装记录等。

8. 《使用手册》 -- 包括产品简介、功能列表、功能描述和解释、功能操作、客户服务和联系方式等。

9. 《维护手册》 -- 包括产品简介、系统须知、初始环境设置、系统配置、数据管理和备份、技术问题解答和联系方式等。

10. 《用户报告》 -- 包括产品简介、购买时间、使用目的、使用时间、使用地点、实施过程、出现问题和解决、产品总结和建议等。

11. 《销售培训》 -- 包括项目简介、产品功能、产品特点、商业优势、系统运行环境、适用范围、目标客户等。 第一、需求分析文档

用户需求分析文档是指在和客户进行沟通时，把用户所要求的信息记录下来，根据用户的要求进行需求分析，规划出我们要开发的软件所要实现哪些功能。

第二、概要设计文档

概要设计：顾名思义，就是对我们所要开发的软件进行一个整体的概括，把这个软件所包含的功能模块作一个设计，以后我们在开发的时候就有目标，有方向了。

第三、系统设计文档

系统设计，就是对概要的一个详细的实施，就是分析我们所要开发软件各大功能模块中所包含的小模块，把这些小模块都一一列举出来，然后再对软件开发人员进行有条理的进行开发任务的分配。

第四、详细设计文档

详细设计文档，主要是把我们每个小模块，小功能的业务逻辑处理用文字的方式表达出来，让程序员在编码的时候有一个依据和参照；同时，在进行详细文档设计的时候，有的软件公司也会根据不同的项目作出相应的《软件开发代码规范》性文档。以保障我们所做工作的统一性。

第五、软件测试文档

当我们参照软件详细设计文档编码完成后，接着就会根据我们所实现的功能，进行软件测试文档的编写；大多测试文档有两类，一类是软件单体测试文档，一类是软件结合测试文档；顾名思义，单体测试：就是对软件中每个小的方法，一个独立的方法进行测试的文档；结合测试：就是把多个功能模块组合到一起进行测试，主要是为了检测每个功能模块之前的交互性和功能的结合实现性。

第六、软件完成后的总结汇报型文档

不管所开发软件的规模大小，在一个软件开发结束后，我们都会把开发过中的问题和项目开发总结一起记录下来，以防以后在开发过程中再有类似问题出现，提高我们的开发效率。

根据软件开发公司的规模、标准和客户的需求不同，开发文档的种类和数量也不同，我在这里和大家讨论的软件开发相关文档都是最基础的；在软件行业有一句话：一个软件能否顺利的完成并且功能是否完善，重要是看这个软件有多少文档，软件开发文档是一个软件的支柱，如果你的开发文档漏洞百出，那么你所开发出来的软件也不可能会好；开发文档的好坏可以直接影响到所开发出来软件的成功与否。

打开自己要复制的simulink文档，是我的simulink文档；

打开word文档，就是自己要添加图的word文档

在simulink的界面中，找到“edit”菜单，在下拉菜单中找到“Copy》》》》”，在选择“matefile”，如图中所示；

回到word文档界面，找到相应的位置，单击鼠标右键，选择“粘贴”

复制结果如下图，这样就不用截图的方法进行复制图片了，同时当图的界面太大的时候也可以进行复制了。

再进行相应的调整，就可以用于word文档 了。

软件文档可以分为开发文档和产品文档两大类。

开发文档包括：《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、《 QA 文档》、《项目总结》等。

产品文档包括：《产品简介》、《产品演示》、《疑问解答》、《功能介绍》、 《技术白皮书》、《评测报告》。

用户文档《安装手册》、《使用手册》、《维护手册》、 《用户报告》、《销售培训》等。

数字内容的存储，分发和娱乐服务。用户为资源社区的注册用户。

1.1. 编写目的

本文档的目的，旨在规范软件开发，推动项目有序正常的进行，使相关人员遵守统一的规范。节省制作相关文档的时间，降低系统实现的风险，加快项目实施进度，做到系统设计的规范性和全面性，以利于系统的设计、实现、测试、维护和版本升级。

1.2. 项目范围

本文档用于软件设计阶段的概要设计，它的上游（依据的基线）是项目需求分析书，它的下游是项目详细设计说明书，并为详细设计说明书提供测试的依据。

软件概要设计的范围是：客户端软件系统总体结构、外部接口、主要部件功能分配、全局数据结构以及部件之间的接口等方面的内容。

2. 软件概述

2.1. 爱私货概括

本文档用于软件设计阶段的概要设计，它的上游（依据的基线）是项目需求分析书，它的下游是项目详细设计说明书，并为详细设计说明书提供测试的依据。

2.2. APP功能

本文档用于软件设计阶段的概要设计，它的上游（依据的基线）是项目需求分析书，它的下游是项目详细设计说明书，并为详细设计说明书提供测试的依据。

就是有多详细写多详细

先写你的项目的用途

版权

数据库的每张表干嘛用的

每个界面的功能

每个按钮的链接

每个类实现什么功能

每个类调用的接口和方法，怎么调用的

越详细越好

软件需求文档格式的标准写法 1．引言 1．1 编写目的 · 阐明开发本软件的目的； 1．2 项目背景 · 标识待开发软件产品的名称、代码； · 列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展

软件开发中文档的编写是一个不可缺少的环节，常见的如《需求分析》、《概要分析》、《数据库设计》等。在“软件人”的阵营里向来存在两种观点，注重文档还是关心代码。

我这里写一个《用户信息模块的概要设计文档》，只列举主要内容了

1.功能描述：用于完成系统用户信息的新增、删除、修改、查询；

2.功能用例：一个主用例用户信息，附加新增、删除、修改、查询4个子用例，操作人员为管理员，图形就不画了，很简单的；

3.业务流程：查询有效范围用户信息——》新增用户信息——》判断当前帐号是否存在——》存在给出提示，反之保存成功提示。

4.约束限制：超级管理员可操作所有（包含删除，我这里考虑仅是逻辑删除、非物理删除）的用户信息；系统管理员可操作除系统管理员、超级管理员外的全部用户信息；单位管理员可操作本单位用户信息；用户帐号信息系统内全局唯一；

5.系统性能：要求同时支持500个并发操作；页面操作响应时间小于1s；页面大小小于1kb；

当前用户所属员工信息不存在时，可直接进行员工信息的添加，并完成用户信息的同步保存，确保事务的完整性；

6.运行环境：依赖系统整体运行环境为准（存在特殊需要注明）；

7.操作实体：用户信息、员工信息、系统日志等。

8.异常处理：如果系统框架中已经提供相关说明，这里仅需要注明符合系统架构异常处理方式即可。

9.外部接口：输入—用户ID，输出—用户信息；

10.其他说明：用户帐号必须定义为字母开头，数字与字母组合，并保证全局唯一；用户密码采用md5算法加密，系统架构已提供相关接口。

11.注意事项：用户帐号不能为空，不能存在空格，不能超过6位；超级用户信息仅在系统初始化中完成其信息写入操作，其他用户无权对其进行修改。

项目组中也不是所有人都必须参与文档的编写，通常业务需求人员、设计人员、架构师、项目经理、小组长占大多数，而且这些人中很多也不是专注于写代码的角色。

一个人的精力有限，不可能总是记忆设计程序时的思路，要求，因此需要用设计文档记录软件开发中的细节内容，以便以后重新涉及时可以查阅和回忆，迅速上手

当前软件设计一般是团队合作，如果想让其他开发人员接手继续设计，详细的设计文档可以使交接过程变得简单，否则先前的设计可能会白做了

在管理层面，项目负责人需要详细的文档，以便总结开发设计过程，使设计完整

综上所述，除非微小项目，一般都需要详细的设计文档，尤其是团队软件开发场合更是必须

IEEE在软件工程术语汇编中的定义：软件工程是：1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；2.在1中所述方法的研究

Fritz Bauer在NATO会议上给出的定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

目前比较认可的一种定义认为：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

《计算机科学技术百科全书》中的定义：软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。

软件工程学的内容

软件工程学的主要内容是软件开发技术和软件工程管理．

软件开发技术包含软件工程方法学、软件工具和软件开发环境；软件工程管理学包含软件工程经济学和软件管理学。

软件工程基本原理

著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理。

（1）用分阶段的生存周期计划进行严格的管理。

（2）坚持进行阶段评审。

（3）实行严格的产品控制。

（4）采用现代程序设计技术。

（5）软件工程结果应能清楚地审查。

（6）开发小组的人员应该少而精。

（7）承认不断改进软件工程实践的必要性。

B.Boehm指出，遵循前六条基本原理，能够实现软件的工程化生产；按照第七条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。

软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。

(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程必须遵循什么原则

围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则：

(1)选取适宜的开发模型

该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。

(2)采用合适的设计方法

在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

(3)提供高质量的工程支撑

工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

(4)重视软件工程的管理

软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。

软件工程是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。

软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。它们是在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法——结构分析或结构设计技术。

把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。总之，采用软件工程方法论可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。

目前划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方法论都影响软件生存周期阶段的划分。在划分软件生存周期的阶段时应该遵循的一条基本原则就是使各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说来，软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。

软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成三个阶段，即问题定义、可行性研究和需求分析。

开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。

维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

下面扼要介绍软件生存周期每个阶段的基本任务和结束标准。

1问题定义

问题定义阶段必须回答的关键问题：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。

通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。

问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。

2可行性研究

这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。

可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。

在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。

可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入要多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。

3需求分析

这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。

用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。

在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。

4总体设计

这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”

首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑下述几类可能的方案：

低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工作。

中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。

高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。

系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统 (最佳方案),并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。

上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。

5详细设计

总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”

这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。

通常用HIPO图（层次图加输入／处理／输出图）或PDL语言（过程设计语言）描述详细设计的结果。

6编码和单元测试

这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。

程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

7综合测试

这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。

最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。

必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。

为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。

通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以决定测试和调试过程什么时候可以结束。

应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，做为软件配置的一个组成成分。

8软件维护

维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。

通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。

虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

软件开发模型

1.瀑布模型

瀑布模型是1970年Winston Royce提出的最早出现在软件开发模型。

2.渐增模型

3.演化模型

4.螺旋模型

5.喷泉模型

6.转换模型

7.智能模型

望采纳。 谢谢