软件制作规范

软件制作规范篇一：软件设计规范范围：CPU 上可以识别的代码和数据。全部的代码总和。 要求：从定义开始的设计。完整性，彻底地定义从无开始的整个设计。这是因为软件之软，也是因为硬件平台的多样性和特殊性。 完整把握，从头设计是第一原则。因为软件世界自己并不能统一，还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。 在这样的视野下，操作系统只是一个部分，一个模块，不同的操作系统任你选择；语言的选择是运行环境的选择（每种语言有每种语言的运行时布局） ；所谓框架只是?类库运行环境?的一种构造。 没有对其负载能力、操作强度进行评估前，这些东西（操作系统、语言、框架）还都不能纳入设计规范。 性能：运行过程的收敛（长时间运行的均态） 。操作强度设计（串行处理速度） ，负载能力设计（并发处理的量）。可靠性设计。 软件问题的 3 个方面： 1、硬件，软件的操作对象和运行软件的数字系统（CPU 系统和数字加速硬件） 2、交互操作（界面） ，专业界面设计 3、软件调度性能，实时的自动化过程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互） ，程控和网络访问的调度（服务器） 。软件项目的 3 个部分：（把 3 个阶段由纵向横过来，进行统筹） 分解文档，集成平台，可维护性要求。 软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方，需要对文档进行恰如其分说明。原则是，每段代码，每处需要理解的地方，如果和总体架构相关，就要有说明。 软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势，软件的各个 方面都需要简化。软件形态、需求分析、文档说明、开发工具等。需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。 软件只有一个，而观察的视角很多。要采用最适合的观察视角，让软件一目了然。 软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为：研究过程和工程过程。研究过程可以通过结果，研究报告反映；工程过程则必须采用过程刻画。 软件规范使用的语言一定要有普遍语义，但描述本身具有特殊性；不能强求它的全球唯一。一定要雄视全体，才能选择正确的立足点，这就要求对目前的软件技术有一个了解；要考虑纳入新的发展，那么规范应该分层，把一般的和具体易变的成分分开；要有具体的指导意义，越具体指导意义越大，但通用性则越小。 所谓架构，可能是十分具体应用的代表；不同类别的应用必然有不同的架构。软件架构本身是?应用架构?。因此，不能规范具体的架构。到是可以做：应用架构规范的规范。 逻辑架构的特殊性。可以判断，任何一款实用的软件采取的软件逻辑抽象都是别样的，特例的逻辑。否则，软件不可能那么轻快实用。软件逻辑，鬼魅也。而需求分析，必须是现实实用的，而不是同构/仿真的这似乎是反对象分析的。因为这里强调的是和软件的交互界面，这个界面远远没有反映现实世界的结构。须知，软件强调的是数据处理，是输入输出。否则，就不能达到最简化。 可能现实世界的结构映射，最适合的方式是数据库 采用纯数据结构进行映射。除此之外，能有更合适的技术吗？ 面向对象建模是吗？那么对象又如何与现实世界的对象绑定在一起呢？ 这再次表明，在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术，有它的有限性。也反映了，包含软件应用在内的现实架构已经固定。 如果软件是数据处理，是输入输出，那么软件结构也就可以确定了！ 可视化、用户操作界面解开了另外的软件世界，因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象，象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。 工业控制也开启了新的软件世界，因为软件要从分离的输入建立?综合感知?，感知到设备状态，然后做出响应。软件有其固有的物理属性，也就是计算的量。算法领域，无论算法的论证多么曲折，求得的结果，物化为软件，总是?早已熟知?的软件。这一区分，是定义软件规范的基石。 算法构造领域是和软件完全不同的领域，算法不是软件。算法类似数学系统。也一如数学系统那样多样。 软件构造。算法总要转化为软件，这就是软件构造问题。寻址系统，数组。软件把自己的生成作为问题，给算法开辟了新的领域。软件生成，是一个?构造编译?问题。手工构造，自动编译。语言的发展，是一个软件生成的历史。所谓统一建模，所谓设计模式，其实都是软件生成的问题。 需求分析。需求分析本质上是独立的。所谓 OOA，面向对象的建模，把程序构造概念上升到需求分析领域可能是不对的。一个先验的，复杂的难于掌握的限制，只会让人对需求分析望而却步；即使勉强掌握，难求对需求分析的创造性发展。需求分析应该专注于需求分析本身，独立发展，一切为了准确、快捷的分析。 需求分析层次高一些，抽象一些，自由一些，这样可以充分表达需求的本质。反而可以促进更高级别的程序自动生成。 软件生成的历史。软件生成是为了解决人机沟通，让?计算机语言?更接近普通人的思维逻辑。把这种?高级计算机语言?翻译成可以执行的代码，就是软件生成（代码生成）的任务。而软件编制是专业人员的事情，因此语言问题的本质其实不那么重要。须知，经过培训，莫尔司码的电报发报可以比说话的语速还快！因此，计算机语言的前途迷茫；实际上也确实迷茫，历史上语言的层出不穷本身就说明了问题，至今仍然如此。在当今，必须建立这样的观点：语言是因人而异的；面对一个语言的时候，要清醒，首先明确?这是为谁设计的语言?；也就是说，需求分析之前的需求是要明确，让什么人来设计软件，然后为他们选择合适的语言。软件生成除了代码生成，还包括另外一个意思：软件构造。这在前面已经论述过了。只是，这里的软件构造机制已经在语言中奠定了。手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复 制，产生大量的代码，应付实际问题的量。立体构造。这里还有一个立体问题，实际问题的构造可能产生立体构造，如同建筑，基本的构件组装出复杂的立体结构。这里是建筑设计师的功劳。可能目前我们在语言层面上混淆不清的关键也在这里，没有区分语言和立体构造的责任。一个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来，带来的问题是：这个构造本身必须能够证明自己是正确的。1）能产生软件 2）构造逻辑上正确，确实能解决应用问题。构造本身有一个属性，它有通用性。根本原理是通用的；总体构造本身具有一般性，也就是抽象性、实际问题无关性；局部构件具有通用性。也就是说，这里存在容器和容量的区别，构造是容器，实际问题是装在容器中的量。一个好的容器要能顶住容量的压力；一个好的建筑架构要能满足负载和抗振性要求。而架构本身的承受能力是客观的，只与架构本身有关。这也就是说，架构本身自我构造的，因此也就是科学。可能软件构造本身是澄清问题的工作，明确?容量?的特点，为软件构造的选择提供准确的依据，杀鸡不要用牛刀。实际问题的?容量?很容易测量，因为它反映为应用的规模，流程的流量。 （架构是什么？架构是否存在？如果我们所说非虚，那么如何为架构下一个定义一定是一个由具体业务流量和模式支撑的架构） 软件（算法）的构造。一个是数据的复杂性（内在互相关系） ，一个是计算方法（步骤和缓冲） 。从宏观角度，数据关系是更根本的东西。目前的高级语言，变量和流程（顺序、分支步骤；循环缓冲和迭代）研究的多，而数据复杂性构造不足。 同构现象。CPU 指令集合可以说是硬件直接实现的软件。软件帝国从这里提取软件精神，并升华它。从硬件的角度，从寄存器和指令执行流程，体现出的是变量和迭代（顺序更迭，循环往复） 。 （迭代流程）基于固定寻址的变量，经过寻址接口，可以处理任意数据，从而把迭代流程变成了一般流程。CPU 的基本过程，产生了指令和数据，指令天生具有子程序的基因（一般流程） ，数据天生具有数据结构（寻址能力）的基因。高级的构造一般也是这种结构的类似：设计一套类似 CPU 的机制，支撑程序和数据；独特的?寻址机制?和?CPU 处理能力?是实现构造的核心机制；迭代是所有这种机制的动力学和构造方式。而数据化是?寻址机制?的基础。抽象是数据化的工厂，也因此必须研究抽象技术。 抽象技术。所谓抽象，就是具体化，是范围的界定和比对（两种具体化对象之间的比对） 。如果范围界定的完整，那么比对建立的联系就是普遍联系，普遍联系也就是所谓抽象原则。评价标准。软件架构需要评测。这种评测是?在商言商?似的评测。评测的基础是软件架构的具体化。当掌握了架构的构造方法，每种架构本身也就具体化，是一种具体的架构。一种具体化的架构，就可以识别；可以识别则可以客观评测。可以按照立体架构的?压力?、?流量?等概念进行评测。 需求的把握需求的变化。我们希望永恒不变的需求，核心需求和需求方式（表现和满足步骤） ；而事实上需求总在演化。软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤，需求源于现实核心深处，软件是一件衣服。这种观点下，软件是没有中心的一种架构。软件架构和需求之间联系的定量评测。 软件和算法的分开 软件的构造作为软件的通用属性 需求的独立 推论：算法是应用的算法。比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法。也因此软件构造是软件规范的一部分，因为它是通用的软件构造技术。 计算技术和应用之间有明显的区别，是两种不同的成分。软件规范是纯粹的，只关心计算技术。而不关心应用建模。计算方法本身早已经被发现了（也就是怎么自动计算，或者说什么是可计算的） ，剩下的问题只是应用问题。把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明。所谓软件设计是把这种计算方式发扬广大。 所谓算法，就是明确问题，然后发现用自动计算的方式解决问题。从这个意义上 篇二：软件设计文档国家标准 GB8567软件设计文档国家标准 GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、 可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。2、 项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、 软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、 概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、 详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、 用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、 测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 8、 测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、 开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。 12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言 11 编写目的说明编写本可行性研究报告的目的，指出预期的读者。12 背景 说明： a所建议开发的软件系统的名称； b本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C该软件系统同其他系统或其他机构的基本的相互来往关系。 13 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 14 参考资料 列出用得着的参考资料，如： a本项目的经核准的计划任务书或合同、上级机关的批文； b属于本项目的其他已发表的文件； C本文件中各处引用的文件、资料，包括所需用到的软件开发标准。| 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。 21 要求 说明对所建议开发的软件的基本要求，如： a功能； b性能； C输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象； d输入说明系统的输入，包括数据的来源、类型、数量、数据的组织以及提供的频度； e处理流程和数据流程用图表的方式表示出最基本的数据流程和处理流程，并辅之以叙述； f在安全与保密方面的要求； g同本系统相连接的其他系统； h完成期限。 22 目标 说明所建议系统的主要开发目标，如： a人力与设备费用的减少； b处理速度的提高； C控制精度或生产能力的提高； d管理信息服务的改进； e自动决策系统的改进； f人员利用率的改进。 23 条件、假定和限制 说明对这项开发中给出的条件、假定和所受到的限制，如： a所建议系统的运行寿命的最小值； b进行系统方案选择比较的时间； c经费、投资方面的来源和限制； d法律和政策方面的限制；e硬件、软件、运行环境和开发环境方面的条件和限制； f可利用的信息和资源； g系统投入使用的最晚时间。 24 进行可行性研究的方法 说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的。摘要说明所使用的基本方法和策略，如调查、加权、确定模型、建立基准点或仿真等。 25 评价尺度 说明对系统进行评价时所使用的主要尺度，如费用的多少、各项功能的优先次序、开发时间的长短及使用中的难易程度。 3 对现有系统的分析 这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚至是一个人工系统。 分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。 31 处理流程和数据流程 说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示，并加以叙述。 32 工作负荷 列出现有系统所承担的工作及工作量。 33 费用开支 列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、材料等项开支以及开支总额。 34 人员 列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。 35 设备 列出现有系统所使用的各种设备。 36 局限性 列出本系统的主要的局限性，例如处理时间赶不上需要，响应不及时，数据存储能力不足，处理功能不够等。并且要说明，为什么对现有系统的改进性维护已经不能解决问题。 4 所建议的系统 本章将用来说明所建议系统的目标和要求将如何被满足。 41 对所建议系统的说明 概括地说明所建议系统，并说明在第 12 章中列出的那些要求将如何得到满足，说明所使用的基本方法及理论根据。 42 处理流程和数据流程 给出所建议系统的处理流程和数据流程。 43 改进之处 按 22 条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。 44 影响 说明在建立所建议系统时，预期将带来的影响，包括：441 对设备的影响 说明新提