软件开发基本原则（一）—— 策略和因素
1 概述
时间 -- 成本 -- 质量（或特性）是评价软件项目成败的三个关键指标，这三个指标之间相互影响和制约，形成了所谓的“项目管理三角形”。要提高质量或增加特性意味着成本和时间的增加，或两者都增加；要在时间不变的前提下缩减开发成本或成本不变的前提下缩减时间则意味着质量的下降或特性的削减。
图 1-1 项目管理三角形
上述分析其实只是理论上的“理想平衡”状态。现实工作中往往出现的情形是：要么时间超过计划，要么成本超过预算，要么质量达不到要求，要么三个指标都达不到预期。
典型例子：
由于客户的压力需要尽量缩减开发时间，由于企业间的竞争和盈利压力需要尽量节约成本，因此需要一个人做两个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审和项目会议等活动。可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。更糟糕的还在后面：由于质量的低劣，构建阶段结束后对系统进行集成测试时，很多问题就会暴露出来：对某些需求的理解有误差，导致这部分功能要重新分析、设计、编码和测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的Bug；沟通不畅顺导致模块接口不兼容……从而项目被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个项目谈虎色变。
软件开发项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。
2 策略和因素
2.1 总体策略
要避免混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发：
1、避免典型错误
2、打好开发基础
3、管理风险，避免灾难发生
4、采用面向进度的实践
图 2.1-1 快速开发的四跟支柱
典型错误：是指一些经常被许多人使用的无效的开发实践，如：不现实的预期，缺乏计划，功能蔓延和银弹综合症等。将在第3章详细讲解。
开发基础：是指项目开发过程中管理、技术、质量保证等方面行为和活动，如：计划编制，需求管理和技术回顾等。将在第4章详细讲解
风险管理：是指对有可能影响项目的风险进行评估和控制。将在第5章讨论进度计划相关的风险。
面向进度的实践有以下三类
?面向速度的实践：可以提升开发速度，帮助你更快的交付软件
?面向进度风险的实践：可以降低计划风险，帮助你的项目平稳推进
?面向可视化的实践：可以提高进程的可视化程度，帮助你掌握项目动态
图2.1-1所示的前三根柱子为可能的最佳进度提供了最重要的支撑，虽然可能不是最理想的，但却是最需要的。也就是说，即使不借助于面向进度的实践方法，也可能实现较优化的项目进度；但是，如果仅仅依赖面向进度的实践却不可以支撑可能的最佳进度计划。
图 2.1-3 仅仅依赖面向进度的实践不足以支撑最佳进度计划
2.2 软件开发的四维
每个软件项目都有四个重要的维：
?人员：完成任务要么快，要么慢
?过程：优化人员的工作效率，或者浪费人员的时间
?产品：以自我完善的形式定义，或者阻碍人员达到最好效果的形式定义
?技术：促进或者阻碍开发的实现
2.2.1 人员
研究数据：
人件极大地影响着生产效率，任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训机制
发挥人员最大潜能，缩短项目周期的方法：
1、项目成员的选择
五个原则：
?用更少更好的人
?使任务与人员的技能和动机相匹配
?帮助人员自我实现，而不是强制地把他推到他最有经验或最需要他的岗位上
?人员选择应强调人员之间的互补与协调性
?尽快排除或替换不称职的人员
2、团队组织结构
人员的组织方式对人员的工作效率有很大影响，调整项目团队以使之与项目规模、产品特点以及进度目标相匹配。特定的软件项目也可以从适宜的专门组织中受益。
3、人员激励
人员激励能激发人的动力，从而付出额外的努力工作；它适用于不同组织、不同项目和不同人员。人员激励是达成快速开发的最具潜力方法
2.2.2 过程
研究数据：
Hughes Aircraft、Lockheed、Motorola、NASA、Raytheon和Xerox等组织通过对开发过程的改进将产品上市时间缩短了一半，降低成本、减少错误为原来的1/3~1/10。
过程是指软件开发生命周期中定义的一系列工作流程和活动的集合。可以概括为以下三类：
?基本过程：包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程
?支持过程：包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程
?组织过程：包括基础设施过程、改进过程以及培训过程
忽略过程容易造成工作效率低下，工作目的交叉重复，产品质量难以保证等问题；另一方面，如果过程过于严格、过于官僚同样会挫伤人员的积极性，或者由于执行过程的成本过高而影响实际的工作效率。
组织可以对现有的过程进行裁剪和调整，制定出适合特定项目的过程；或者可以为项目从头开始定义过程。无论是裁剪过程或是定义过程，应该把关注点放在以下几个方面：
1、避免返工
软件项目节省时间一个最直接的方式就是确定过程，避免重复工作。如果在项目最后阶段改变需求，就可能不得不重新设计、编码和测试；如果直到系统测试阶段才发现设计有问题，就可能不得不扔掉已经细化的设计和编码。
2、质量保证
质量保证有两个目的
?确保交付的产品能够达到可接受的质量水平
?在各阶段以最少的时间和成本代价查出错误
应尽早在错误发生的时候就查出来，错误在产品中停留的时间越长，清楚错误所花费的时间和成本就越多。质量保证是任何开发过程中必不可少的部分。
3、开发基础
一系列的软件工程实践活动形成了开发基础，如：分析、设计、构建、集成和测试等。在过程中对开发基础加以关注，并定义良好的工作规范和任务集合能防止项目失控。
4、风险管理
与进度相关的风险管理是开发过程必要的组成部分。风险管理虽然不能直接提高开发速度，但它是避免项目灾难的有效实践。
5、资源目标
资源包括人力资源、环境资源和软硬件资源等。优化资源的调配有助于提高生产率。
6、生命周期计划
生命周期计划是基本的管理计划，有助于确定软件项目要进行的活动集合和资源分配。每种周期模型都有其适用范围和缺点，为项目选择适当的生命周期模型能有效提高工作效率或降低项目风险。
图 2.2.2-1 纯瀑布模型
图 2.2.2-2 瀑布模型的另一种形式——鲑鱼生命期模型
图 2.2.2-3 编码修正模型（一种不规范的模型）
图 2.2.2-4 螺旋模型
图 2.2.2-5 生鱼片模型
图 2.2.2-6 包含子项目的瀑布模型
图 2.2.2-7 能够降低风险的瀑布模型（对需求分析和架构设计阶段采用螺旋模型）
图 2.2.2-8 渐进原型模型
图 2.2.2-9 阶段交付模型
图 2.2.2-10 面向进度模型
图 2.2.2-11 渐进交付模型
图 2.2.2-12 面向开发工具的设计模型
7、面向客户开发
谁是客户？
对客户的理解取决于场合，可能是项目委托人，最终用户，市场人员或者老板。
现代软件开发非常关注客户的需求与期望，开发出合符产品规格的软件只是完成了一半工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些功能所花费的时间通常远远多于确定纸面上的产品规格所需要的时间。
将自己站在客户的角度考虑问题是避免大量返工的最好方法。同时应该建立有效的客户沟通渠道，合理控制客户的期望值。
2.2.3 产品
在软件开发的四维中，最切实的维是产品维。对产品规模和产品特性的关注，意味着巨大的缩短计划进度的机会。削减了产品功能通常就可以缩短产品开发周期
1、产品规模
产品规模是对开发进度影响最大的一个因素。构建软件所需的工作量的增长比产品规模的增长要快得多，并且增长是不成比例的，所以产品规模的缩小将大大提高开发速度。将中等规模的软件削减一半通常可以使工作负荷削减2/3。
2、产品特性
产品的一些非功能性需求或额外关注点会影响设计的复杂度和构建的工作量，如对性能、稳定性、可维护性和可扩展性等要求很高的产品比没有这些特性要求的产品需要更长的开发周期。
2.2.4 技术
从使用低效的工具转为使用高效的工具是提高开发速度的快捷方法。选择有效的工具并管理好由此带来的风险也是提高开发速度的方法。
软件开发基本原则（二）—— 典型错误
大多数典型错误其表面都具有诱惑性，给人们一种诱人的前景，但通常却不能产生期望的结果。
“想挽救进度已经落后的项目吗？---- 给项目补充更多人员！”
下面分别按照人员、过程、产品和技术四个维度列出36个典型错误。
人员
典型错误1：挫伤积极性
对人员不够关心和重视；过度的进度压力；缺乏激励；过分夸张的激励等。
典型错误2：人员素质低
人员能力欠佳，工作效率低，甚至做多错多。
典型错误3：对有问题的员工失控
不对有问题的人员采取措施是项目组成员对领导最常见的抱怨。
典型错误4：英雄主义
强调个人英雄主义会导致发生额外的风险，也会削弱在软件开发过程中多个角色的合作。
典型错误5：项目后期加入人员
盲目地在项目后期加入人手等于火上浇油。
典型错误6：办公室环境拥挤嘈杂
拥有安静、隐蔽办公环境的人员比工作在嘈杂、拥挤环境中的人员往往会有更好的工作业绩表现。
典型错误7：开发人员与客户之间发生摩擦
主要原因是缺乏沟通。这种摩擦耗费时间，它会转移客户和开发人员双方对项目工作的注意力。
典型错误8：不现实的预期
过高的期望值和主观的不切实际的设想。是导致开发人员和客户或项目经理之间的摩擦常见原因之一。
典型错误9：缺乏有效的项目支持
软件开发项目的许都方面都需要高层的支持，包括实际的计划、变更控制以及新型开发方法的采用等。缺乏有效的高层支持事实上注定了项目的失败。
典型错误10：缺乏各种角色的齐心协力
软件开发中所有主要人员必须齐心协力专注于项目，包括高层支持者、项目领导、项目成员、市场人员、最终用户、客户和任何项目介入者。
典型错误11：缺乏用户介入
没有用户早期介入的项目充满需求误解的风险，易受项目后期功能蔓延的威胁。
典型错误12：政治高于物质
“政治家”型项目强调“管理至上”，主要精力集中在他们与经理的关系上。将政治凌驾于结果之上对软件项目会造成极大伤害。
典型错误13：充满想象
闭上眼睛毫无理由地希望某事将像想象那样运作。很多软件开发问题都是由于充满想象造成的。
想象示例：
项目组不知道他们能不能按时完成项目，但他们认为如果每个人能更努力工作，并且不出现问题，他们应该能完成项目。
我们无需向客户演示最新的修改，我们确信这个效果是客户想要的。
项目组错过了一个里程碑好几天了，他们说会更努力工作赶上下一个里程碑，我想他们能够及时赶上的。
过程
典型错误14：过于乐观的计划
定制过于乐观的项目计划相当于自己为项目失败画出了底线，导致缩短分析、设计等关键性前期开发活动；同时也向开发人员施加了额外压力，会长期对开发人员的自信心和生产率造成巨大伤害。
典型错误15：缺乏足够的风险管理
如果你不主动管理风险，风险随时会来找你，打乱你的开发计划。
典型错误16：承包人导致的失败
如果不对承包商加以认真管理，交付可能延期，并且质量难以保证。
典型错误17：缺乏计划
没有计划的项目就像飘荡在海洋中的小船，没人知道会飘到哪里。
典型错误18：在压力下放弃计划
很多项目组定制了计划，但遇到了麻烦时就放弃计划。项目失败的原因不是在于放弃计划本身，而是不能及时修订计划制定替代计划，并一头栽进编码和问题处理中。
典型错误19：在模糊的项目前期浪费时间
由于花在审批、预算等前期工作的时间过长，或需求无限循环等原因，导致压缩开发计划。项目前期节省几周或几个月时间比将开发计划压缩同样时间来得更容易、更廉价，风险也更少。
典型错误20：前期活动不符合要求
研究数据：
前期被跳过的活动或工作通常在后期会以10倍到100倍的代价来完成。如果一项工作在项目初期需要5小时完成，那么在项目后期你至少需要50小时才能完成它。 （Fagan 1976，Boehm and Papaccio 1988）
典型错误21：设计低劣
前期活动不符合要求的一个特殊情况就是设计低劣。高压环境导致设计缺乏周密思考往往导致设计低劣。
典型错误22：缺少质量保证措施
研究数据：
项目前期砍掉1天的质量保证活动，到项目后期就需要3到10天的处理代价。（Jones 1994）
典型错误23：缺少管理控制
缺少管理控制点就难以对项目的阶段和状态进行跟踪，因此不能知道项目是否按正常轨道前进。
典型错误24：太早或过于频繁的集成
在构建未完全锁定时，进行过早的集成或额外的集成不利于产品，它仅仅是在浪费时间，延长进度。
典型错误25：项目估算时遗漏必要的任务
训、公司和部门会议，技术评审会议等活动在项目估算时通常被遗漏。
典型错误26：追赶计划
当进度落后时不重新检查任务和调整计划，而是简单地决定把进度赶上来。
另一种情况是，当产品出现变更却没有做相应的计划调整
典型错误27：鲁莽编码
没有足够的需求基础和清晰的架构设计而进行“边编码边修改”造成太多重复工作和返工，这样的做法使项目大多以失败告终
产品
典型错误28：需求的镀金
项目的产品要求要求比实际需求多得多的产品特性或复杂功能，却又不给进度计划分配足够的时间。
典型错误29：功能蔓延
在整个开发过程中，项目平均会有25%的需求变更，对软件计划至少有25%的影响。如果任由客户不断提出新需求，项目就会一直都做不完
典型错误30：开发人员的镀金
开发人员着迷于新技术，有时渴望在自己的产品中使用这些技术，而不管那些技术是否适合或是否会对系统整体造成破坏。
典型错误31：又推又拉的交易
管理者批准进度落后的项目顺延，但同时又给这个项目加入新任务。
典型错误32：研究导向的开发
软件开发进度是完全有理由可以预测的，而软件研究进度甚至理论上都是不可预知的，不能采用像软件研究一样的工作方式引导项目开发。
技术
典型错误33：银弹综合症
过于相信某些技术宣传（某种开发过程、某种程序设计方法、某种开发语言），缺少在特定环境下使用这些工具的必要信息。当团队寄望利用他们来解决进度问题时，不可避免会失败的。
典型错误34：过高估计了新技术或方法带来的节省量
无论采用多少新工具或方法，以及这些工具或方法有多好，他们很少能够大幅度提高生产率。软件开发由多个任务组成，特定的工具或方法只会可能提高特定任务的生产效率。同时，它们所带来的效率常常被学习它们所花费的时间抵消了。
典型错误35：项目中间切换工具
在项目中间更换工具时，伴随使用新工具而带来的人员学习和掌握的过程、重复的工作、不可避免的错误等会彻底抵消它所带来的益处。
典型错误36：缺乏自动的源代码控制手段
缺乏自动的源代码控制容易造成版本冲突、历时版本丢失、更新丢失等一系列问题，并浪费大量的时间处理这些问题。
软件开发基本原则（三）—— 基本原则
“回顾一下被选为‘最佳项目’的十个软件项目，如果说有所发现的话，那就是——最佳的项目一定是建立在最佳的软件开发基础之上的。我们都知道软件开发基础对于优秀软件的作用，但差别在于大多数软件的基础薄弱，这样不可避免地使自己陷入麻烦之中”
（Bill Hetzel 1993）
本章的范畴只限定在确定软件开发的基本原则，解析他们是如何影响开发计划的，同时提供参考信息。
本章书把软件开发基本原则实践分为三类：管理实践，技术实践和质量保证实践。
管理的基本原则
管理原则由以下几部分组成：
判定产品规模（包括功能、复杂度和其它产品特性）
根据产品规模分配资源
制定资源计划
监控、引导资源以保持项目方向不会偏离
1. 项目估算和进度安排
一个运行良好的项目一般通过三个基本步骤来定制软件开发进度表。
首先估算项目规模大小
然后估算完成这样规模的项目需要付出的代价
最后基于这种估算定制项目进度计划
如果估算不准确就会降低开发效率，所以说估算和项目进度计划是软件开发的基础。精确的估算时进行有效规划的必要前提，而有效的规划又是有效开发的必要条件。
质量管理体系 计算机软件设计、开发专业审核指导书 1适用范围 本指导书适用于计算机软件设计、开发专业 2 术语 软件：与计算机系统的操作有关的程序、规程、规则及任何与之有关的文档。软件生存周期（Life cycle）：软件产品从构思开始至软件不再可用结束的时间周期。软件生存周期典型地包括：需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段、操作和维护阶段有时还包括退役阶段。 软件工程：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。 软件配置项：软件配置管理的对象，指的是软件工程过程中产生的所有信息项。包括计算机可执行的源代码、目标代码、数据库等以及计算机不可执行的文档、源程序清单、测试用例等。 软件配置管理：标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件测试：为了发现错误而执行程序的过程，或者说是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。 黑盒测试：又叫功能测试或数据驱动测试。只依据程序的需求规格说明书，检查
程序的功能是否符合它的功能说明，而不考虑程序内部的逻辑结构和内部特性。白盒测试：又叫结构测试或逻辑驱动测试。测试人员利用程序内部的逻辑结构以及有关信息，涉及或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。 基线（Baseline）：已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理过程方能加以修改的规格说明或产品。 CMM：软件过程能力成熟度模型，可用于对软件过程评估和软件能力评价。单元测试：又称模块测试，是针对软件设计的最小单元——程序模块，进行正确性检验的测试工作。 集成测试：把软件部件、硬件部件或者两者组合起来进行的测试。 系统测试：将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。 回归测试：用于验证对软件修改后又没有引出新的错误，或者说，验证修改后的软件是否仍然满足系统的需求规格说明。 代码评审/走查：由若干程序员和测试员组成一个评审小组，通过阅读、讨论和争议，对程序进行静态分析，确定程序中是否有某类错误或“危险”结构的过程。Bug：缺陷或隐错 编码（coding）：即为程序编写，把软件设计转换成计算机可以接受的程序代码（即写成以某一种特定程序设计语言表示的“源程序清单”）的工作。 软件需求说明书：也称软件规格说明书。对所开发软件的功能、性能、用户界面、及其运行环境等做出详细的说明。是用户与开发人员双方对软件需求取得共同理
231 GB 8567－88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567－88中主要软件文档的编写说明，供编写时参考。这些文档主要是：可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明：说明本可行性研究报告的编写目的，指出预期的读者。 1.2 背景 说明： a ．所建议开发的软件系统的名称。 b ．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c ．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料，如： a ．本项目的经核准的计划任务书或合同、上级机关的批文。 b ．属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提，如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求，如： a ．功能。 b ．性能。 c ．输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e ．处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程，并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标，如： a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。
《基础工程》课程设计 ——某办公楼桩基础设计 一：设计资料 1、建筑场地土层按其成因土的特征和力学性质的不同自上而下划分为四层，物理力学指标见下表。地下水位在地面以下 2.0m ，地下水水质分析结果表明，本场地下水无腐蚀性。 建筑安全等级为Ⅱ级，已知作用到基础顶面处的柱荷载： 轴向力kN F K 2850=，力矩m kN M ?=0.395，水平力kN H 42=。 2、根据地基条件和施工设备，采用钢筋混凝土预制桩，以黄土粉质粘土为桩 尖持力层。 钢筋混凝土预制桩断面尺寸为400mm ×400mm 。桩长根据地质勘察资料和《规 范》知一般应选择硬土层作为桩端持力层故确定第3层粘土为桩端持力层。查《规范》和经验知：桩顶嵌入承台0.1m 。由题目要求知采用钢筋混凝土预制桩，故由经验选择选择桩截面为方桩，为400mm ×400mm ，桩长至少为2m+9m+0.1m=11.1m 查规范知桩端嵌入持力层为5d-10d 故选择5d ，所以桩长为11.1+5x0.4=13.1m 故选择桩长为13m 。有《规范》知承台埋深一般为1-2米，选承台埋深为D=2m ，桩端进持力层2m 。初步确定承台尺寸为2×2m 。 3、桩身混凝土强度为C35，所以，轴心抗压强度设计值 f c ＝ 16.7MPa ，弯曲强度设计值为f m ＝19MPa ，主筋采用：4Φ18，强度设计值： f y ＝310MPa 4、承台混凝土强度为C30。轴心抗压强度设计值为 f c ＝14.3MPa ，弯曲抗压强度设计值为 f m ＝16.5MPa 。 设计要求： 1、单桩竖向承载力标准值和设计值的计算； 2、确定桩数和桩的平面布置图； 3、群桩中基桩的受力验算 4、承台结构设计及验算； 5、桩及承台的施工图设计：包括桩的平面布置图，桩身配筋图， 承台配筋和必要的施工说明； 6、需要提交的报告：计算说明书和桩基础施工图。
软件/系统设计的总体思路 一、概念 软件设计的本质就是针对软件的需求，建立模型，通过将模型映射为软件，来解决实际问题。因此软件设计需要解决的核心问题是建立合适的模型，使得能够开发出满足用户需求的软件产品，并具有以下特性： ?灵活性（Flexibility） ?有效性（Efficiency） ?可靠性（Reliability） ?可理解性（Understandability） ?维护性（Maintainability） ?重用性（Reuse-ability） ?适应性（Adaptability） ?可移植性（Portability） ?可追踪性（Traceability） ?互操作性（Interoperability） 因此，软件设计并没有一套放之四海而皆准的方法和模板，需要我们的设计开发人员在软件的设计开发过程中针对软件项目的特点进行沟通和协调，整理出对软件项目团队的行之有效的方式，进行软件的设计。并保障软件设计文档的一致性，完整性和可理解性。
我们经常听到这样的话： ?“设计文档没有用，是用来糊弄客户和管理层的文档”； ?“用来写设计文档的时间，我的开发早就做完了”； ?“项目紧张，没有时间做设计”； 这些言论，并不是正确的观念，根据软件项目的实际情况，软件开发设计团队可以约定设计文档的详细程度。项目团队需要保障设计文档的完整性和一致性，在项目进度紧张的情况下，软件设计文档可以更初略一些；在项目时间充裕的情况下，相关文档可以更为详尽。但是在项目开发过程中，需要软件设计开发团队对于设计文档有共同的理解。 二、设计文档分类与使用 通常来说，作为软件项目，我们需要有这几类文档 ?需求说明文档 ?功能设计文档 ?系统架构说明书 ?模块概要设计文档 ?模块详细设计文档 就像我之前说到的，在某个软件团队，对于以上的文档的要求是可以完全不同的，在简单项目中，可能所有类型的文档放在一个文档中进行说明；在复杂项目中，每一类文档可能都要写几个文档；而在最极端的情况下，可能每一类文档都能装
软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied = stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false
= SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));
【最新资料,Word版，可自由编辑！】
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (4) 2.技术过程规范部分 (4) 2.1 概述 (4) 2.2 业务建模阶段 (4) 2.3 需求阶段 (6) 2.4 分析设计阶段 (8) 2.5 实现阶段 (10) 3.管理过程规范部分 (11) 3.1 概述 (11) 3.2 接受项目 (12) 3.3 重新评估项目范围和风险（对于较大项目） (12) 3.4 制定开发计划 (13) 3.5 迭代开发管理 (13) 3.6 监控项目的实施 (14) 3.7 结束项目 (15)
软件开发过程规范 前言 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。
PLC 控制系统设计的基本原则 来源： https://www.doczj.com/doc/8312647975.html, 任何一种控制系统都是为了实现被控对象的工艺要求，以 提高生产效率和产品质量。因此，在设计PLC 控制系统时，应遵循以下基本原则： 1. 最大限度地满足被控对象的控制要求 充分发挥PLC 的功能，最大限度地满足被控对象的控制要求，是设计PLC 控制系统的首要前提，这也是设计中最重要的一条原则。这就要求设计人员在设计前就要深入现场进行调查研究，收集控制现场的资料，收集相关先进的国内、国外资料。同时要注意和现场的工程管理人员、工程技术人员、现场操作人员紧密配合，拟定控制方案，共同解决设计中的重点问题和疑难问题。 2. 保证PLC 控制系统安全可靠 保证PLC 控制系统能够长期安全、可靠、稳定运行，是设计控制系统的重要原则。这就要求设计者在系统设计、元器件选择、软件编程上要全面考虑，以确保控制系统安全可靠。例如：应该保证PLC 程序不仅在正常条件下运行，而且在非正常情况下（如突然掉电再上电、按钮按错等），也能正常工作。 3. 力求简单、经济、使用及维修方便 一个新的控制工程固然能提高产品的质量和数量，带来巨大的经济效益和社会效益，但新工程的投入、技术的培训、设备的维护也将导致运行资金的增加。因此，在满足控制要求的前提下，一方面要注意不断地扩大工程的效益，另一方面也要注意不断地降低工程的成本。这就要求设计者不仅应该使控制系统简单、经济，而且要使控制系统的使用和维护方便、成本低，不宜盲目追求自动化和高指标。 4. 适应发展的需要
由于技术的不断发展，控制系统的要求也将会不断地提高，设计时要适当考虑到今后控制系统发展和完善的需要。这就要求在选择PLC、输入/输出模块、I/O点数和内存容量时，要适当留有裕量，以满足今后生产的发展和工艺的改进。 ［返回 ]
工艺设计的基本原则和程序 一、工艺设计的基本原则 水泥厂工艺设计的基本原则可归纳如下： (1)根据计划任务书规定的产品品种、质量、产量要求进行设计。 计划任务书规定的产品产量往往有一定范围，设计产量在该范围之内或略超出该范围，都应认为是合适的；但如限于设备选型，设计达到的产量略低干该范围，则应提出报告，说明原因，取得上级同意后，按此继续设计。 对于产品品种，如果设计考虑认为计划任务书的规定在技术上和经济上有不适当之处，也应提出报告，阐明理由，建议调整，并取得上级的同意。例如，某大型水泥厂计划任务书要求生产少量特种水泥，设计单位经过论证，认为大型窑改变生产品种，在技术上和经济上均不合理，建议将少量特种水泥安排给某中小型水泥厂生产，经上级批准后，改变了要求的品种。 窑、磨等主机的产量，除了参考设备说明和经验公式计算以外，还应根据国内同类型主机的生产数据并参考国内外近似规格的主机产量进行标定。在工厂建成后的较短时期内，主机应能达到标定的产量；同时，标定的主机产量应符合优质、高产、低消耗和设备长期安全运转的要求，既要发挥设备能力，但又不能过分追求强化操作。 (2)选择技术先进、经济合理的工艺流程和设备。 工厂的工艺流程和主要设备确定以后，整个工厂设计可谓大局已定。工厂建成后，再想改变其工艺流程和主要设备，将是十分困难的。例如，要把湿法厂改为干法厂，固然困难；要把旧干法厂改为新型干法厂，也非易事。例如，为了利用窑尾废气余热来烘干原料，生料磨系统也得迁移，输送设备等也得重新建设，诸如此类的情况，在某些条件下就不一定可行。 在选择生产工艺流程和设备时，应尽量考虑节省能源，采用国内较成熟的先进经验和先进技术；
7个软件开发原则 关于代码重复最著名的单词是Kent Beck的Once And Only Once，也就是说软件操作的任何一个片断--不管是一个算法，一个常量集合，用于阅读的文档或者其他东西--应当只出现一次。软件重复出现至少会导致以下问题： ·其中的一个版本会过期 ·代码的责任会四处散开，导致代码难以理解 ·当你修改代码时，需要重复修改很多地方，一不小心就会遗漏 ·你不能很好地进行性能优化 重复代码的产生有各种各样的原因，程序员把几行或一整段代码从这里复制到这里，然后少加修改，就变成了一份新的代码。这里的原因是程序员可以通过极少的努力就完成代码重用，但是我们可以来看看DavidHooker提出的7个软件开发原则: 1.第一原则：存在的理由(Pattern: TheReason) 一个软件系统存在的理由就是：为它的用户提供价值。你所有的决定都取决于这一点。在指定一个系统需求，在写下一段系统功能，在决定硬件平台和开发过程之前，问你自己一个问题，“这样做会为系统增加价值吗？“，如果答案是”yes”，做。如果是”No”,不做。这个原则是其他原则的原则。 2．第二原则（能简单就简单，愚蠢！）KISS (Pattern: KeepItSimple) 软件设计不是一个轻描淡写的过程。在做任何一个设计时，你必须考虑很多因素。所有设计应当尽可能简单，但是不要再比这简单了。这样产生的系统才是可以理解和容易维护的。这并不是说很多由意义的特性，因为这种简单性也要被抛弃。确实很多更优雅的设计往往更简单，但简单并不意味着“quick and dirty."。事实上，简单是通过许多思考和一次一次的反复修改才达到的。这些努力的汇报就是更容易维护，代码错误更少。（看看是否违反） 3．第三原则：保持远见(Pattern: MaintainTheVision) 清晰的远见是一个软件项目成功的基础。没有这样的远见，项目开发最后就变成天天为一个不好的设计做补丁。Brooks说过：概念的完整性是系统设计中最重要的问题。 Stroustrup 也说：有一个干净的内部结构识构建一个可理解、可辨识、可维护、可测试系统的基础。 Booch则总结道：只有当你对系统的体系由一个清晰的感觉，才可能去发现通用的抽象和机制。开发这种通用性最终导致系统更简单，因此更小，更可靠如果你不断地复制、粘贴、修改代码，最终你将陷入一个大泥潭(the Big Mud),你永远不可能对系统有一个清晰的认识。 4.第四原则：你制造的，别人会消费 (Pattern: WhatYouProduceTheyConsume) 软件系统不是在真空中使用的。其他人会使用、维护、文档你的系统。这依赖于对你系统的理解。所以，你设计、实现的东西应当能够让别人理解。要记住，你写的代码并非只给计算机看，你要时时记住，代码还要给人看。(Kent Beck) 如果到处泛滥似是而非的代码，别人如何能够辨别这些代码的相似和不同，如何去理解这些代码之间具有何种关系。 5．第五原则：对将来开放( Pattern BuildForTodayDesignForTomorrow) 一个成功的软件有很长的生命期。你必须能够使得软件能够适应这样和那样的变化。所以，一开始就不要软件设计到死角上去。请总是问一下自己“如果这样，那么。。？“这个问题，你要考虑到各种各样的可能性，而不光光是图省事。复制，粘贴一下即可。 6．第六原则：为重用做好计划 软件模式是重用计划的一种。不断重复的代码显然不是这样的计划。 (See CommentsOnSix) 7．第七原则：思考！ 在采取任何动作之前首先做一个清晰、完整的考虑，这样才能产生更好的结果。如果你考虑了，但还是产生错误的结果，那么这种努力也是值得的。在你学习或研究类似的问题时，更容易理解和掌握。 这些原则告诉我们轻松地复制、粘贴和修改代码不可能产生好的，也就是容易理解、维护、重用的代码。
软件开发规范 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】
附2: 软件文档编写向导 文档分类 项目包括如下几类文档： 项目管理文档。包括：《软件项目计划》、《项目进度报告》、《项目开发总结报告》 软件开发文档。包括：《需求规格说明》、《概要设计说明》、《详细设计说明》、《测试计划》、《软件测试分析报告》。 产品文档。包括：《用户操作手册》《演示文件》。 软件项目计划 （Software Project Plan） 一．引言 1．编写目的（阐明编写软件计划的目的，指出读者对象。） 2．项目背景（可包括：（1）项目委托单位、开发单位和主管部门；（2）该软件系统与其他系统的关系。） 3．定义（列出本文档中用到的专门术语的定义和缩略词的原文。） 4．参考资料（可包括：文档所引用的资料、规范等；列出资料的作者、标题、编号、发表日期、出版单位或资料来源。） 二．项目概述 1. 工作内容（简要说明项目的各项主要工作,介绍所开发软件的功能性能等. 若不编写可行性研究报告,则应在本节给出较详细的介绍。)
2. 条件与限制（阐明为完成项目应具备的条件开发单位已具备的条件以及尚需 创造的条件. 必要时还应说明用户及分合同承包者承担的工作完成期限及其它条件与限制。） 3. 产品 （1）程序（列出应交付的程序名称使用的语言及存储形式。） （2）文档（列出应交付的文档。） （3）运行环境（应包括硬件环境软件环境。） 4．服务（阐明开发单位可向用户提供的服务. 如人员培训安装保修维护和其他运行支持。） 5．验收标准 三．实施计划 1．任务分解（任务的划分及各项任务的负责人。） 2．进度（按阶段完成的项目,用图表说明开始时间完成时间。） 3．预算 4．关键问题（说明可能影响项目的关键问题,如设备条件技术难点或其他风险因素,并说明对策。） 四．人员组织及分工 五．交付期限 六．专题计划要点（如测试计划等。） 项目开发进度报告 一．报告时间及所处的开发阶段 二．给出进度 1．本周的主要活动 2．实际进展与计划比较
施工组织设计的基本原则 ①配套投产,根据建设项目的生产工艺流程、投产先后顺序,都要服从施工组织总设计的规划和安排。安排各单位工程开竣工期限，满足配套投产； ②确定重点,保证进度； ③建设总进度一定要留有适当的余地; ④重视施工准备,有预见地把各项准备工作做在工程开工的前头； ⑤选择有效的施工方法,优先采用新技术、新工艺，确保工程质量和生产安全; ⑥充分利用正式工程,节省暂设工程的开支； ⑦施工总平面图的总体布置和施工组织总设计规划应协调一致、互为补充。 施工组织设计一般分为三个阶段: 1、施工条件设计(或称施工组织基本概况); 2、施工组织总设计； ３、各个建筑物等单位工程的施工设计。 施工组织设计目录 一、编制说明 二、编制依据 三、工程概况 1、工程名称及规模
２、工程范围及内容 3、建筑与结构 4、电气工程 5、给排水工程 ６、采暖工程 ７、材料做法 8、工期要求 ９、质量要求 10、安全及环保要求 1１、自然条件 12、施工条件 13、相关单位 二、施工总体组织及规划１、总体主导思路 2、项目管理组织 ３、施工队伍部署及任务划分4、施工准备 ５、各部门职责 6、施工总平面布置 7、总体施工组织方案 ８、施工工期目标规划 9、工程质量目标规划
10、安全、文明施工与环保目标规划 三、施工进度计划安排 1、总工期计划安排 ２、工程项目阶段性目标计划 ３、施工进度计划横道图 四、劳动力计划安排 五、主要施工机械设备配备 六、主要材料（设备)供应进度计划 七、主要分部、分项工程施工方法技术及措施 1、施工测量 2、基坑(槽)土方开挖与回填 ３、基础工程施工 4、模板工程 5 、钢筋工程 ６、砼工程 ７、砖砌体工程施工 8、室内墙面、天棚装修 9、窗安装 10、普通地砖地面 11、外墙外保温 1２、脚手架工程 １３、屋面防水施工
软件开发过程规范 版本 <1.0> 修订历史纪录
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (3) 2.技术过程规范部分 (3) 2.1 概述 (3) 2.2 业务建模阶段 (4) 2.3 需求阶段 (5) 2.4 分析设计阶段 (6) 2.5 实现阶段 (7) 3.管理过程规范部分 (7) 3.1 概述 (7) 3.2 接受项目 (8) 3.3 重新评估项目范围和风险（对于较大项目） (8) 3.4 制定开发计划 (8) 3.5 迭代开发管理 (9) 3.6 监控项目的实施 (9) 3.7 结束项目 (10)
软件开发过程规范 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 1.3 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。
系统中涉及的所有规范、标准或材料规格（包括一切有效的补充或附录）均采用最新版本，即以招标方与投标方签订供货合同之日作为采用最新版本的截止日期。若发现本规范书与参照的文献之间有不一致之处，我方向贵方书面指明，并由贵方确定采用哪一个规范。 我方所有设备的设计，制造，检查，试验及特性除本规范中规定的特别标准外，都遵照适用的最新版中国国家标准（GB）以及国际单位制（SI）。 我方提出的等同标准应不低于贵方要求的标准并征得贵方的认可，我方应遵循的标准至少包括： 《中华人民共和国计算机信息系统安全保护条例》 GB2887－89 计算站场地技术条件 GB/T 9361－1988 计算机场地安全要求 GB4943－90 信息技术设备（包括电气事务设备）的安全 GB/T －1995 中华人民共和国计算机信息安全保护条例 GB18030－2000 信息交换用汉字编码字符集基本集的扩充 GB1526－89信息处理－数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文字编制符及约定
GB8566 计算机软件开发规范 GB9385 计算机软件需求说明编制指南 GB9386 计算机软件测试文件编制规范 GB/T13502 信息处理、程序构造及其表示法的约定 GB/T14085 信息处理系统计算机系统配置图符号及约定GB10112 确立术语的一般原则与方法 GB/T13725 确立术语数据库的一般原则与方法 SJ/T11293 企业信息化技术规范 GB/T12504－90 计算机软件配置管理计划规范 GB/T13702－92 计算机软件分类与代码 GB/T14079－93 软件工程术语 GB/T15532－1995 计算机软件单元测试 GB/T 14394－1993 《计算机软件可靠性和可维护性规范》GB/T 2887－1989 《计算机软件质量保证规范》 GB/T 8566－2000 《信息技术软件生成期过程》
施工组织设计的基本原则 ①配套投产，根据建设项目的生产工艺流程、投产先后顺序，都要服从施工组织总设计的规划和安排。安排各单位工程开竣工期限，满足配套投产； ②确定重点，保证进度； ③建设总进度一定要留有适当的余地; ④重视施工准备，有预见地把各项准备工作做在工程开工的前头； ⑤选择有效的施工方法，优先采用新技术、新工艺，确保工程质量和生产安全； ⑥充分利用正式工程，节省暂设工程的开支； ⑦施工总平面图的总体布置和施工组织总设计规划应协调一致、互为补充。 施工组织设计一般分为三个阶段： 1、施工条件设计(或称施工组织基本概况)； 2、施工组织总设计； 3、各个建筑物等单位工程的施工设计。 施工组织设计目录 一、编制说明 二、编制依据 三、工程概况 1、工程名称及规模
2、工程范围及内容 3、建筑与结构 4、电气工程 5、给排水工程 6、采暖工程 7、材料做法 8、工期要求 9、质量要求 10、安全及环保要求 11、自然条件 12、施工条件 13、相关单位 二、施工总体组织及规划 1、总体主导思路 2、项目管理组织 3、施工队伍部署及任务划分 4、施工准备 5、各部门职责 6、施工总平面布置 7、总体施工组织方案 8、施工工期目标规划 9、工程质量目标规划
10、安全、文明施工与环保目标规划 三、施工进度计划安排 1、总工期计划安排 2、工程项目阶段性目标计划 3、施工进度计划横道图 四、劳动力计划安排 五、主要施工机械设备配备 六、主要材料(设备)供应进度计划 七、主要分部、分项工程施工方法技术及措施 1、施工测量 2、基坑（槽）土方开挖与回填 3、基础工程施工 4、模板工程 5 、钢筋工程 6、砼工程 7、砖砌体工程施工 8、室内墙面、天棚装修 9、窗安装 10、普通地砖地面 11、外墙外保温 12 、脚手架工程 13、屋面防水施工
软 件 开 发 流 程 规 范 V1.0 德联软件有限责任公司
编制人：侯秀美审核人：2015 年8 月19 日
目录 目录 0 一、概述 (2) 二、开发流程规范 (3) 2.1 系统软硬件开发环境 (3) 2.2 系统架构（系统组成） (5) 2.3 系统功能模块设计 (6) 2.4 系统功能开发流程图 (6) 2.5 开发修改记录 (7) 三、开发代码规范 (8) 3.1 文件结构 (8) 3.1.1 文件信息声明 (8) 3.1.2 头文件的结构 (10) 3.1.3 定义文件的结构 (11) 3.1.4 头文件的作用 (12) 3.1.5 目录结构 (13) 3.2 命名规则 (13) 3.2.1 共性原则 (13) 3.2.2 Windows变量命名规则 (14) 3.3 程序风格 (17) 3.3.1 空行 (17) 3.3.2 代码行 (18) 3.3.3 代码行内的空格 (19) 3.3.4 对齐 (21) 3.3.5 长行拆分 (22) 3.3.6 修饰符的位置 (23) 3.3.7 注释 (23) 3.4 函数设计 (26) 3.4.1 参数的规则 (26) 3.4.2 返回值的规则 (27) 3.4.3 函数内部实现的规则 (30) 3.4.4 其它建议 (32) 3.4.5 使用断言 (32) 3.4.6 引用与指针的比较 (33) 3.5 变量类型定义 (35) 四、软件测试规范 (36) 4.1 单元测试 (36) 4.2 系统测试 (37) 4.6 业务测试 (38)
4.7 验收测试 (38) 4.8 用户现场测试 (39) 五、软件版本管理 (39) 4.1版本管理的必要性 (39)
项目组 软件开发行为规范 仅供信息化部使用
1 概述 1.1 编写目的 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以到达提高系统质量的目的。在本规范中，阐述了基本的开发模式，包括需求验证、设计、编码规范、代码审查、单元测试、配置管理等，并明确开发过程中的方法、策略、工具以及环境要求，开发人员都必须遵守本软件开发规范。 1.2 读者对象 本规范读者对象为软件开发项目管理者、项目经理、开发组 2需求评审 2.1过程要求 按软件开发过程经验，问题暴露越早越好。因此，在实施设计和编码前，需对项目经理提供的需求说明文档进行充分的验证，在不明确的需求点上，需要和项目经理进一步核实，确保对每个需求点有清晰、一致的认识和理解。 在需求验证的过程中，需按以下检查点进行逐项检查（包括不限于）： 1.所有定义、实现方法是否清楚地表达了用户的原始要求？ 2.是否清楚、明确地描述了所有的功能？是否没有不能理解或造成误解的 描述？ 3.需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有
需求？ 4.需求是否可以验证（即是否可以检验软件是否满足了需求）？ 5.是否有术语定义一览表？ 6.是否标识并定义了在将来可能会变化的需求？ 7.各个需求之间是否一致？是否有冲突和矛盾？ 8.是否定义了系统所有的输入、输出及其来源？主要为客户或者其他外部 接口，是否明确定义了输入参数和输出参数？ 9.是否说明了如何进行系统输入的合法性检查？ 10.功能性需求是否覆盖了所有非正常情况的处理？ 11.对异常数据产生的结果是否作了精确的描述？ 12.是否充分定义了关于人机界面的需求？ 13.在不同情况下，是否规定了系统的响应时间？ 14.界面需求是否使软硬件系统具有兼容性？ 15.是否有对相关日志做明确要求？以满足稽核相关的需要。 针对开发过程中的需求变更，以上需求验证点同样适用，并同时评估需求变更给当前项目的设计和开发带来的风险，包括架构、安全、进度等方面，以便项目经理进行计划调整和安排。 2.2工具及环境 1.在此过程中，使用Excel对以上检查点进行跟踪和标记。记录文档需check-in 到svn. 2. 评审完成的需求文档需check-in到svn。 3.任何需求变更文档需check-in到svn。
安全仪表（SIS）系统设计原则 SIS 安全仪表系统(ESD紧急停车系统)的主要作用是在工艺生产过程发生危险故障时将其自动或手动带回到预先设计的安全状态，以确保工艺装置的生产的安全，避免重大人身伤害及重大设备损坏事故。在安全仪表系统的设计过程中，IEC 61508，IEC 61511提供了极好的国际通用技术规范和参考资料，在安全仪表系统回路设计过程中，一般需要遵循下列几点原则。 1、SIS 安全仪表系统(ESD紧急停车系统)设计的安全性原则 为了保证工艺装置的生产安全，安全仪表系统必须具备与工艺过程相适应的安全完整性等级SIL（Safety Integrity Level）的可靠度。对此，IEC 61508进行了详细的技术规定。对于安全仪表系统，可靠性有两个含义，一个是安全仪表系统本身的工作可靠性；另一个是安全仪表系统对工艺过程认知和联锁保护的可靠性，还应有对工艺过程测量，判断和联锁执行的高可靠性。 评估安全完整性等级SIL的主要参数就是PFDavg(probability of failure on demand 平均危险故障率)，按其从高到低依次分为1~4级。在石化行业中一般涉及到的只有1，2，3级，因为SIL4级投资大，系统复杂，一般只用于核电行业。 2、SIS 安全仪表系统(ESD紧急停车系统)设计的可用性原则 为了提高系统的可用性，SIS 安全仪表系统(ESD紧急停车系统)应具有硬件和软件自诊断和测试功能。安全仪表系统应为每个输入工艺联锁信号设置维护旁路开关，方便进行在线测试和维护同时减少因安全仪表系统系统维护造成的停车。需要注意的是用于三选二表决方案的冗余检测元件不需要旁路，手动停车输入也不需要旁路。同时严禁对安全仪表系统输出信号设立旁路开关，以防止误操作而导致事故发生。如果SIL计算表明测试周期小于工艺停车周期，而对执行机构进行在线测试时无法确保不影响工艺而导致误停车，则安全仪表系统的设计应当根据需要进行修改，通过提高冗余配置以延长测试周期或采用部分行程测试法，对事故状态关闭的阀门增加手动旁通阀，对事故状态开启的阀门增加手动截止阀等措施，以允许在线测试安全仪表系统阀门。这些手段对于提供安全仪表系统的可用性都是很有帮助的。 3、SIS 安全仪表系统(ESD紧急停车系统)设计的独立性原则 SIS 安全仪表系统(ESD紧急停车系统)应独立于基本过程控制系统（BPCS，如DCS，FCS，CCS，PLC等），独立完成安全保护功能。安全仪表系统的检测元件，控制单元和执行机构应单独设置。如果工艺要求同时进行联锁和控制的情况下，安全仪表系统和BPCS应各自设置独立的检测元件和取源点（个别特殊情况除外，如配置三取二检测元件，进DCS信号三取中，进安全仪表系统三取二，经过信号分配器公用检测元件）。如需要，SIS 安全仪表系统(ESD紧急停车系统)系统应能通过数据通信连接以只读方式与DCS 通信，但禁止DCS通过该通信连接向安全仪表系统写信息。安全仪表系统应配置独立的通信网络，包括独立的网络交换机，服务器，工程师站等。SIS 安全仪表系统(ESD紧急停车系统)应采用冗余电源，由独立的双路配电回路供电。应避免安全仪表系统和BPCS的信号接线出现同一接线箱，中间接线柜和控制柜内。 SIS 安全仪表系统(ESD紧急停车系统)设计的标准认证原则 随着安全标准的推出以及对安全系统重视度的不断提高，安全仪表系统的认证也变得越来越重要，系统的设计思想，系统结构都须严格遵守相应国际标准并取得权威机构的认证。安全仪表系统必须获得IEC 61508 SIL和/或TUV AK（德）相应SIL等级的认证。SIS 安全仪表系统(ESD紧急停车系统)中使用的硬件，软件和仪表必须遵守正式版本并已商业化，同时必须获得国家有关防爆，计量，压力容器等强制认证。严禁使用任何试验产品。5、故障安全原则 当SIS 安全仪表系统(ESD紧急停车系统)的元件，设备，环节或能源发生故障或者失
第三章工艺流程设计 第一节概述 工艺流程设计和车间布置设计是工艺设计的两个主要内容，是决定工厂的工艺计算、车间组成、生产设备及其布置的关键步骤。 生产工艺流程设计在整个工艺设计中最先开始，但随着工艺及其他专业设计的展开，通常需要对初步的工艺流程设计进行局部修改，所以几乎是最后才完成。 生产工艺流程设计的主要任务包括两个方面：其一是确定由原料到成品的各个生产过程及顺序，即说明生产过程中物料和能量发生的变化及流向，应用了哪些生物反应或化工过程及设备。其二是绘制工艺流程图。 在发酵生产过程中，原料往往不是直接变成产品，而是通过一系列的半成品或中间产品再变成成品，同时还有副产品和废液、废渣等生成，“三废”必须严格治理。 因为工艺流程设计是最关键的设计，与其他专业设计息息相关，所以需要由浅人深和分阶段进行。同时必须经过反复推敲，精心安排和计算，不断修改和完善，才能完成设计任务。 生产工艺流程的设计往往经历三个阶段，即：生产工艺流程示意图、生产工艺流程草图、生产工艺流程图。 具体地说，生产方法和生产规模确定后就可以开展设计生产工艺流程示意图。工艺流程示意图作出后，就可以进行物料衡算和能量衡算以及部分设备计算和选型。待设备设计全部完成后，再修改、充实工艺流程草图，根据流程草图和设备设计进行车间布置设计。根据车间布置图再来修改工艺流程草图，最后得出生产工艺流程图。 当然上面介绍的示意图、草图、流程图的设计程序并非一成不变，还需根据设计项目的难度、技术的成熟程度、设计人员水平及实践经验等多方面因素决定。若设计人员经验丰富，而且是难度不大、技术成熟的项目，甚至可以一次完成生产工艺流程图的设计。 第二节生产方法的选择和工艺流程的设计原则 生产工艺流程设计是整个工艺设计的基础，工艺流程图是指导施工的重要图纸。通常，生产方法的选择和工艺流程设计，是决定设计成败的关键工作。 一、生产方法的选择 生产方法即工艺路线的选择，是生物工程工厂设计的关键步骤。一般要对可选择的各种生产方法进行全面的比较分析，从中选出技术先进、经济合理的工艺路线，以保证项目投产后能达到高产、低耗、优质和安全运转。 以发酵工厂为例，介绍选择生产方法的主要依据。 1．原料来源、种类和性质 如需应用进口原料如啤酒生产的麦芽，则必须采取先进的生产方法和技术，以保证生产出高质量的产品，供出口或内销。原料的种类和性质不同，则生产方法也要相应改变。对酒精生产，采用糖蜜或淀粉作原料，则工艺路线就大不相同。即便是淀粉质原料，也有谷类、薯类原料和野生植物淀粉质原料之分，其工艺流程也有一定差异。 2.产品的质量和规格 糖蜜原料发酵生产三级酒精，可采用两塔式液相过塔蒸馏流程；若生产一级或优级酒精，则必须采用三塔式或多塔式流程。又如啤酒生产中，淡色啤酒或浓色啤酒的糖化、煮沸工艺就不相同。 3．生产规模 工厂的设计生产能力对工艺流程的选择也有影响。生产规模较小时，可采用分批发酵法；对于大型企业，则采用连续发酵工艺有利于生产过程的机械化、自动化和稳产高产的实现。 4.技术水平 生产方法的选择也必须考虑技术水平。如酒精生产，连续发酵技术要求较高的操作技术，而间歇生产则较易掌握。又如味精生产，应用糖蜜原料发酵谷氨酸的方法，具有产酸高、经济效益好的优点，但对菌种和生产技术水平要求严格。所以生产工艺既要考虑先进性，又要保证切实可行。
软件开发基本原则（一）——策略和因素 概述 时间成本质量（或特性）是评价软件项目成败的三个关键指标，这三个指标之间相互影响和制约，形成了所谓的“项目管理三角形”。要提高质量或增加特性意味着成本和时间的增加，或两者都增加；要在时间不变的前提下缩减开发成本或成本不变的前提下缩减时间则意味着质量的下降或特性的削减。 图项目管理三角形 上述分析其实只是理论上的“理想平衡”状态。现实工作中往往出现的情形是：要么时间超过计划，要么成本超过预算，要么质量达不到要求，要么三个指标都达不到预期。 典型例子： 由于客户的压力需要尽量缩减开发时间，由于企业间的竞争和盈利压力需要尽量节约成本，因此需要一个人做两个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审和项目会议等活动。可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。更糟糕的还在后面：由于质量的低劣，构建阶段结束后对系统进行集成测试时，很多问题就会暴露出来：对某些需求的理解有误差，导致这部分功能要重新分析、设计、编码和测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的；沟通不畅顺导致模块接口不兼容……从而项目被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个项目谈虎色变。 软件开发项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。 策略和因素 总体策略 要避免混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发： 、避免典型错误