下载文档原格式
软件概要设计评审要点一、引言软件概要设计评审是软件开发过程中的重要环节，通过对软件概要设计方案进行评审，可以及时发现和解决设计问题，确保软件开发过程顺利进行。
本文将就软件概要设计评审的要点进行详细介绍，帮助相关人员进行有效的软件概要设计评审。
二、概要设计文档的完整性在评审软件概要设计时，首先需要确保概要设计文档的完整性，包括但不限于以下几个方面：1. 文档完整性：评审人员需要确保概要设计文档覆盖了所有的功能需求、非功能需求以及系统性能指标，避免遗漏重要的设计内容。
2. 设计描述清晰明了：文档中的设计描述需要清晰明了，避免出现模糊不清的描述，使得评审人员无法准确理解设计方案。
3. 设计目标明确：概要设计文档需要明确定义软件的设计目标和需求，确保设计方案符合业务需求和用户期望。
三、设计方案的合理性和可行性评审软件概要设计还需要重点关注设计方案的合理性和可行性：1. 设计方案的逻辑和结构是否合理：评审人员需要评估设计方案的逻辑结构是否合理，是否满足系统的功能和性能需求，是否符合工程实践和设计原则。
2. 可扩展性和维护性：评审人员需要评估设计方案的可扩展性和维护性，确保设计方案可以轻松的扩展新功能，并且易于维护和修改。
3. 技术可行性：评审人员需要评估设计方案的技术可行性，包括评估所采用的技术是否成熟、是否能够满足系统的性能需求、是否易于实现等。
四、设计文档的规范性和格式化评审软件概要设计还需要关注设计文档的规范性和格式化：1. 文档格式规范：评审人员需要确保概要设计文档的格式规范，包括文档的标题、编号、目录、页眉页脚、图表表格等元素的规范设置。
2. 文档的表述规范：评审人员需要注意设计文档的表述是否准确、清晰、简洁明了，避免出现歧义和误解。
3. 术语定义和缩写规范：评审人员需要确保文档中的术语定义明确、缩写规范，避免出现术语混淆和缩写混乱。
五、设计方案的优劣势分析评审软件概要设计中还需要对设计方案的优劣势进行分析：1. 优点突出：评审人员需要明确指出设计方案的优点和亮点，包括但不限于设计方案的创新性、性能优势、成本优势等。
浅谈软件项目需求评审流程在实际的软件项目过程中,需求阶段往往是由一两位需求分析人员与用户沟通用户需求,然后根据自己的理解输出软件需求说明书及软件原型。
需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将自食其果。
因此,如何保证需求分析的正确、准确性,成了决定软件项目成败的关键因素。
目前,很多小型软件企业在需求阶段,往往是需求人员写完需求后再跟用户沟通一下,就直接进入设计开发阶段了,设计、编码、测试人员前期没有参与进来,根本没有进行需求评审。
也有不少企业的需求评审存在“走过场”的情况,其他人员根本不关心软件需求,认为软件需求就是需求分析人员的事情,他们怎么写大家怎么做就可以了,在提需求异常时简单找几个错别字提一下应付了事,没有提出有效的需求异常。
也有的时候,在需求评审会议中,大家的关注点常常会不知不觉的转向设计,结果需求评审会议成了设计讨论会议,大家想得最多的是需求如何实现,而不是需求文档本身有无问题。
或者是因为没有做好前期准备工作,导致评审时间长、效率低,结果很多问题不了了之。
这样的评审,最终效果可想而知。
下文根据笔者多年参与软件项目管理的切身体会及经验,从不同角度对需求评审方法进行论述。
1、充分准备评审。
好的软件需求说明书,是进行有效需求评审的前提。
首先,需求人员在与用户确认需求的过程中,一定不要放过任何一个细节,仔细体会用户的每一个要求。
对于用户的要求,需求人员需要对其加以梳理:哪些是合理的需求,哪些是不合理的需求,还有一些可能是必要的但是用户没想到的需求。
软件需求说明书不应该只是用户意愿的表达,而应该是从软件层面上对用户需求的总结。
软件需求说明书对需求用例的描述一般分为基本流和扩展流,基本流是大家很容易想到的主要业务流程,而实际设计开发及测试过程中,最耗费时间的是实现扩展流的过程。
因此不能只注重基本流,好的软件需求说明书,扩展流一定远远多于基本流,扩展流写得越完善,说明需求人员考虑得越周全。
为保证软件在开发、测试、发布及使用过程中版本正确，应用有效，制定本流程。
2、适用范围适用于试生产、量产、工程定制软件等的开发、审批、发布。
3、职责3.14、流程活动说明4.1提出软件开发需求系统设计工程师根据客户新需求、产品可维护性提高、软件使用情况提出软件需求。
技术部经理根据反馈问题、客户需求变更、生产工艺修改优化、电路版本升级、软件质量问题等情况分析提出软件开发需求。
产品工程师根据生产效率提升等需要提出软件开发需求或根据软件实际使用的情况提出软件修改的需求。
4.2组织评审，确定需求、判定是否紧急产品经理会同需求提出者、开发人员、测试人员，对需求进行评审，确定需求，确定测试项目。
4.3软件开发子流程开发人员根据更改的需求，进行分析并给出初步的修改方案，实施软件的修改。
修改过程中，在软件代码中要求标注修改的地方，修改完成并经过自身测试完成后，要求给出软件修改说明、软件版本号，适用的范围。
4.4制定测试方案，搭建测试平台测试人员根据修改的需求以及开发人员更改的方案，制定测试方案，搭建测试平台。
4.5将软件提交测试人员开发人员将软件提交测试人员。
4.6软件测试子流程测试人员根据需求以及测试方案开展测试。
在软件改动较大,涉及面比较广的情况下,由项目经理协调测试人员开展相应的软件测试工作。
4.7是否通过测试人员判定软件是否通过。
如通过，进行7.8。
如不通过，返回7.3。
4.8上传配置库，提交电子流开发人员将软件及版本说明等，上传配置库相应位置，同时提交“软件审批电子流”。
电子流应注明软件在配置库中的地址，并以附件附上版本说明文件。
测试人员在电子流上确认。
4.10审批产品经理通过电子流，针对软件开发需求对测试报告及数据进行审批。
4.11是否通过产品经理判定是否通过。
4.12发布办公室从配置库下载软件及版本说明，上传到服务器共享目录相应位置，并发邮件通知软件、测试、生产相关人员。
共享目录按产品/项目，及“试生产软件”、“量产软件”、分类。
软件评审流程软件评审是软件开发过程中非常重要的一环，它能够有效地帮助团队发现和解决问题，提高软件质量，保证项目的顺利进行。
下面将介绍一般的软件评审流程，希望能够对大家有所帮助。
1.确定评审对象。
在进行软件评审之前，首先需要确定评审的对象，包括需求文档、设计文档、代码、测试用例等。
评审对象的确定需要根据项目实际情况和阶段来进行，确保评审的全面性和针对性。
2.召集评审人员。
确定评审对象后，需要召集评审人员参与评审活动。
评审人员一般包括项目经理、开发人员、测试人员等相关人员，他们应具备丰富的经验和专业知识，能够对评审对象进行全面、深入的分析和评价。
3.准备评审材料。
评审人员需要提前准备评审材料，包括评审议程、评审表格、相关文档等。
评审材料的准备要充分考虑评审对象的特点和重点，确保评审的有效性和高效性。
4.进行评审会议。
评审会议是软件评审的重要环节，评审人员在会议中对评审对象进行分析和讨论，发现问题并提出改进意见。
评审会议需要有明确的议程和主持人，确保会议的秩序和效果。
5.记录评审结果。
评审会议结束后，需要及时记录评审结果，包括发现的问题、改进意见、责任人等。
评审结果的记录要清晰明了，便于后续跟踪和处理。
6.跟踪问题解决。
评审结束并记录评审结果后，并不意味着评审活动的结束，评审人员需要跟踪评审发现的问题，确保问题得到及时解决并进行验证。
7.总结评审经验。
评审活动结束后，需要对评审活动进行总结，包括评审的效果、存在的问题、改进的建议等。
总结评审经验可以帮助团队不断改进评审流程，提高评审的效率和效果。
以上就是一般的软件评审流程，希望能够对大家有所启发。
在实际项目中，评审流程可能会有所调整，但总体的目标都是为了提高软件质量，保证项目的顺利进行。
希望大家能够重视软件评审工作，共同努力提升团队的整体水平。
软件工程中的软件工程项目评审和验收在软件工程中，软件工程项目评审和验收是非常重要的环节。
项目评审和验收旨在确保软件项目的质量和可靠性，以满足用户的需求和期望。
本文将介绍软件工程项目评审和验收的概念、流程以及关键考虑因素。
一、概念软件工程项目评审是指在软件开发过程中，对项目进展、达成的里程碑和交付物进行全面和系统性的检查和评估。
项目评审旨在确保项目按照计划和要求进行，并及时发现和解决潜在的问题和风险。
评审可以包括项目计划、需求文档、设计文档、代码、测试计划等方面的内容。
软件工程项目验收是指在软件开发完成后，对软件产品进行检验和验证，以确认软件产品符合用户要求和期望。
验收可以包括功能测试、性能测试、安全性测试、用户界面测试等方面的内容。
验收的目标是确保软件产品的质量和稳定性，并提供用户满意的用户体验。
二、流程软件工程项目评审和验收的流程可以分为以下几个阶段：1. 需求评审：在项目启动阶段，对用户需求进行评审和验证。
评审会议由项目经理和相关利益相关者参与，目的是明确需求、澄清疑问，并确认开发方案。
2. 设计评审：在需求阶段之后，对软件系统设计进行评审。
评审团队通常包括项目经理、系统架构师、开发人员等。
评审的目标是确保设计符合需求、可行性和可维护性。
3. 编码评审：在编码阶段，对开发人员编写的代码进行评审。
评审的目标是确保代码的质量、可读性和可维护性。
评审过程通常由一个或多个开发人员进行，可以使用静态代码分析工具来辅助评审。
4. 测试评审：在测试阶段，对测试计划、测试用例以及测试结果进行评审。
评审的目标是确保测试的全面性和准确性，并发现和修复潜在的问题和风险。
5. 用户验收：在软件开发完成后，由用户对软件进行最终验收。
用户验收旨在确认软件是否符合用户要求和期望，并提供用户满意的用户体验。
如果软件未能通过验收，则需要返回开发团队进行修改和再次验收。
三、考虑因素在进行软件工程项目评审和验收时，需要考虑以下因素：1. 质量标准：确定评审和验收的质量标准，包括功能性、性能、安全性、可靠性等方面的要求。
软件评审流程一、概述。
软件评审是指对软件产品进行全面审查和评定的过程，旨在确保软件产品的质量和可靠性，以满足用户需求和预期。
软件评审流程是软件开发过程中的重要环节，对于提高软件质量、减少软件缺陷、提升用户满意度具有重要意义。
二、软件评审的类型。
1. 静态评审，静态评审是在软件开发过程中对文档、代码等静态成果进行审查，包括需求评审、设计评审、代码评审等。
静态评审通过检查和讨论的方式，发现问题并及时进行修正，有利于提前发现和解决潜在的问题，降低软件开发成本。
2. 动态评审，动态评审是在软件产品已经开发完成后进行的测试和验证，包括单元测试、集成测试、系统测试等。
动态评审通过运行程序并观察其行为，验证软件产品是否符合需求规格和设计要求，以及是否存在功能缺陷和性能问题。
三、软件评审流程。
1. 制定评审计划，在软件开发过程开始阶段，制定评审计划是软件评审流程的第一步。
评审计划应包括评审的时间安排、评审的范围和内容、评审的参与人员等信息，确保评审工作有条不紊地进行。
2. 召集评审会议，根据评审计划，召集评审会议是软件评审流程的关键环节。
评审会议应邀请相关人员参与，包括项目经理、开发人员、测试人员、用户代表等，共同对软件产品进行评审。
3. 进行评审活动，评审会议上，评审人员根据评审计划进行评审活动，对软件产品进行全面审查和讨论。
评审活动应注重细节，发现问题并提出改进建议，确保评审工作的深入和全面。
4. 形成评审报告，评审活动结束后，形成评审报告是软件评审流程的总结阶段。
评审报告应包括评审的结果、发现的问题、改进建议等信息，为软件开发人员提供参考和指导。
四、软件评审的好处。
1. 提高软件质量，通过软件评审流程，可以及时发现和解决软件产品中的问题和缺陷，提高软件产品的质量和可靠性。
2. 降低软件开发成本，软件评审可以在软件开发早期发现问题并进行修正，避免问题逐步扩大导致成本增加。
3. 提升用户满意度，软件评审可以确保软件产品符合用户需求和预期，提升用户的满意度和信任度。
软件产品评审流程要点1. 立项市场需要（软件为用户解决什么样的问题）国家政策（国家是否有相关政策提出，是否有利于该软件日后的发展）产品定位（软件在行业中的定位）产品功能策划市场上类似产品的功能、特点与优势产品的卖点与优势开发该软件对公司的（战略）意义性能（效率、响应时间、资源占用、稳定性）重要等级（是否直接关系人员生命安全）工程实施复杂度和软件维护复杂度开发的（技术）风险是什么市场或公司允许的研发周期预计成本（人力物力）（可验证性）2. 设计方案概要设计：提交概要设计文档，内容包括如下方面：总体设计（需求规定、运行环境、基本设计概念和处理流程、结构、功能需求与程序的关系、人工处理过程、尚未解决的问题）接口设计（用户接口、外部接口、内部接口）运行设计（运行模块组合、运行控制、运行时间）系统论据结构设计（逻辑结构设计要点、物理结构设计要点、数据结构与程序的关系）系统出错处理设计（出错信息、补救措施、系统维护设计）详细设计：提交详细设计文档，内容包括如下方面：术语定义及说明详细设计方法和工具系统详细需求分析（详细需要分析、接口需求分析）总体方案确认（系统总体结构确认、系统详细界面划分（应用系统与支撑系统的详细界面划分、系统内部详细界面划分））系统详细设计（系统结构设计及子系统划分、系统功能模块详细设计、系统界面详细设计（外部、内部以及用户界面设计））数据库系统设计（设计要求、信息模型设计、数据库设计（设计依据、数据库选型、数据库种类及特点、数据库逻辑结构、物理结构设计、数据库安全、数据字典））网络通信系统设计（设计要求、网络结构确认、网络布局设计、网络接口设计）信息编码设计（代码结构设计、代码编制）维护设计（系统的可靠性和安全性、系统及用户维护设计、系统扩充、错误处理（出错类别、出错处理））、系统调整及再次开发问题系统配置（配置原则、硬件配置、软件配置）关键技术（关键技术的提出、关键技术的一般说明、关键技术的实现方案）组织机构及人员配置投资预算概算及资金规划实施计划（限制、实施内容和进度安排、实施条件和措施、系统测试计划（测试策略、测试方案、预期的测试结果、测试进度计划））、验收标准3. 技术选型版权是否有应用先例，是否为常用技术类似的技术是否在公司内部使用过使用此技术的额外风险是什么（有没有失败的案例，原因是什么，如何避免）此技术是否是过时的技术（技术没有发展前景，或者提供者将来不再提供技术升级等）是否为成熟的技术（应用范围广，大公司或者标准组织提供）能有选择的，尽量不要用定制的技术（其它类似产品或者项目不能复用的技术尽量少用）4. 界面评审指导原则：关注用户及其任务，而不是技术首先考虑功能，然后才是表示从用户的视角看问题，使用用户的词汇进行描述，不必向用户暴露实现细节使常用的用户任务简单化，不要让用户解决额外的问题促进学习，保持一致性，引导用户的使用习惯保持显示惯性，传递信息，而不仅仅是数据设计应满足响应需求颜色：统一色调：采用标准Windows的基本色调，做到与操作系统统一，读取系统标准色表。
软件测试评审流程软件测试评审就像是一场对软件这个“小怪兽”的全方位检查大会。
一说起软件测试评审，那得先从测试计划评审开始。
想象你要盖一栋房子，这测试计划评审就像是在看盖房子的蓝图有没有问题。
测试计划得把要测试啥，咋测试，谁来测试这些事儿都说明白。
比如说要测试一个购物软件，测试计划里就得写清楚是要测用户注册登录的流程，还是商品下单付款的流程，又或者是退换货的流程。
测试的方法呢，是手动点点点，还是用一些自动化的工具来测。
谁来做这些测试工作，是专门的测试团队，还是开发人员自己也得参与一部分。
这时候参与评审的人就像一群经验丰富的建筑师傅，他们得看看这个蓝图有没有遗漏啥重要的部分，有没有啥地方不合理。
如果发现测试计划里只写了要测试登录注册，却把商品搜索这个重要功能给忘了，那就得赶紧让修改计划的人补上。
再就是测试用例评审啦。
测试用例就像是一个个对付软件“小怪兽”的招式。
每个测试用例都针对软件的某个功能或者特性。
拿社交软件来说，测试用例可能是发送一条文字消息，看看能不能正常发送出去，接收方能不能正常收到，文字有没有乱码之类的。
在评审的时候呢，大家就像武林高手过招一样。
有的高手就会说，你这个测试用例只考虑了发送普通文字消息，要是发送的是一大串表情符号呢，软件会不会崩溃呀。
还有人可能会指出，这个测试用例没有考虑到网络不好的情况，要是网络信号只有一格的时候，消息还能不能发出去。
这时候就得对测试用例进行修改完善，让这些“招式”更加全面，无懈可击。
然后是测试执行结果评审。
这就像是打完仗之后盘点战果。
测试人员把软件这个“小怪兽”一顿操作之后，得到了很多测试结果。
有的结果是好的，比如登录功能测试了100次，每次都成功登录了。
但也可能有不好的结果，像购物软件在结算的时候偶尔会出现金额计算错误。
这时候参与评审的人就会围坐在一起，像一群侦探一样分析这些结果。
为啥会出现金额计算错误呢，是代码里有个小虫子，还是测试环境有问题。
如果是代码的问题，就得让开发人员赶紧去排查修复。
有效的软件技术评审方法与流程软件技术评审是软件开发过程中的一个重要环节，旨在确保软件的技术可行性、可维护性和可扩展性。
为了完成一个完整的软件技术评审，需要输出语句完整、内容完整的报告。
本文将围绕软件技术评审展开讨论，首先介绍软件技术评审的目的和意义，然后阐述软件技术评审的内容和流程，接着介绍如何提高软件技术评审的效率和质量，最后对全文进行总结。
一、软件技术评审的目的和意义软件技术评审的目的是确保软件的技术可行性、可维护性和可扩展性，以满足用户需求。
通过软件技术评审，可以发现潜在的技术问题、缺陷和风险，并采取相应的措施进行优化和改进，从而提高软件的质量和可靠性。
同时，软件技术评审也有助于降低开发成本、缩短开发周期、提高开发效率。
二、软件技术评审的内容和流程1.评审内容软件技术评审的内容主要包括以下几个方面：（1）技术可行性评估：评估所采用的技术是否符合要求，是否具备实现软件所需的功能和性能。
（2）技术风险评估：识别和分析在软件开发过程中可能遇到的技术难题和风险，并提出相应的解决方案。
（3）代码质量评估：对代码的结构、可读性、可维护性和可扩展性进行评估，确保代码质量符合要求。
（4）性能评估：对软件的性能进行测试和评估，确保软件能够满足用户的需求。
（5）安全评估：对软件的安全性进行评估，确保软件在运行过程中不会出现安全漏洞和隐患。
2.评审流程软件技术评审的流程一般包括以下几个步骤：（1）确定评审目标：明确评审的目的和范围，确定需要评审的内容和技术指标。
（2）制定评审计划：根据评审目标和范围，制定详细的评审计划，包括评审时间、地点、人员、方法等。
（3）准备评审材料：根据评审计划准备相应的技术文档、代码、测试报告等评审材料。
（4）执行评审：按照评审计划和流程，对评审材料进行深入的分析和研究，发现问题并提出改进意见和建议。
（5）编写评审报告：根据评审结果编写详细的评审报告，包括问题清单、改进意见和建议等。
（6）反馈与跟踪：将评审报告反馈给相关人员，并跟踪问题的解决情况，确保改进措施得到有效执行。
软件产品评审流程要点1.立项●市场需要（软件为用户解决什么样的问题）●国家政策（国家是否有相关政策提出，是否有利于该软件日后的发展）●产品定位（软件在行业中的定位）●产品功能策划●市场上类似产品的功能、特点与优势●产品的卖点与优势●开发该软件对公司的（战略）意义●性能（效率、响应时间、资源占用、稳定性）●重要等级（是否直接关系人员生命安全）●工程实施复杂度和软件维护复杂度●开发的（技术）风险是什么●市场或公司允许的研发周期●预计成本（人力物力）●（可验证性）2.设计方案概要设计：提交概要设计文档，容包括如下方面：●总体设计（需求规定、运行环境、基本设计概念和处理流程、结构、功能需求与程序的关系、人工处理过程、尚未解决的问题）●接口设计（用户接口、外部接口、部接口）●运行设计（运行模块组合、运行控制、运行时间）●系统论据结构设计（逻辑结构设计要点、物理结构设计要点、数据结构与程序的关系）●系统出错处理设计（出错信息、补救措施、系统维护设计）详细设计：提交详细设计文档，容包括如下方面：●术语定义及说明●详细设计方法和工具●系统详细需求分析（详细需要分析、接口需求分析）●总体方案确认（系统总体结构确认、系统详细界面划分（应用系统与支撑系统的详细界面划分、系统部详细界面划分））●系统详细设计（系统结构设计及子系统划分、系统功能模块详细设计、系统界面详细设计（外部、部以及用户界面设计））●数据库系统设计（设计要求、信息模型设计、数据库设计（设计依据、数据库选型、数据库种类及特点、数据库逻辑结构、物理结构设计、数据库安全、数据字典））●网络通信系统设计（设计要求、网络结构确认、网络布局设计、网络接口设计）●信息编码设计（代码结构设计、代码编制）●维护设计（系统的可靠性和安全性、系统及用户维护设计、系统扩充、错误处理（出错类别、出错处理））、系统调整及再次开发问题●系统配置（配置原则、硬件配置、软件配置）●关键技术（关键技术的提出、关键技术的一般说明、关键技术的实现方案）●组织机构及人员配置●投资预算概算及资金规划●实施计划（限制、实施容和进度安排、实施条件和措施、系统测试计划（测试策略、测试方案、预期的测试结果、测试进度计划））、验收标准3.技术选型●●是否有应用先例，是否为常用技术●类似的技术是否在公司部使用过●使用此技术的额外风险是什么（有没有失败的案例，原因是什么，如何避免）●此技术是否是过时的技术（技术没有发展前景，或者提供者将来不再提供技术升级等）●是否为成熟的技术（应用围广，大公司或者标准组织提供）●能有选择的，尽量不要用定制的技术（其它类似产品或者项目不能复用的技术尽量少用）4.界面评审指导原则：●关注用户及其任务，而不是技术●首先考虑功能，然后才是表示●从用户的视角看问题，使用用户的词汇进行描述，不必向用户暴露实现细节●使常用的用户任务简单化，不要让用户解决额外的问题●促进学习，保持一致性，引导用户的使用习惯●保持显示惯性，传递信息，而不仅仅是数据●设计应满足响应需求颜色：●统一色调：采用标准Windows的基本色调，做到与操作系统统一，读取系统标准色表。
●整个界面色彩尽量少的使用类别不同的颜色。
除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色●同时色调也具有一定的含义，在整个系统中应保持色调含义的一致性，避免同一中颜色在不同的画面中表示不同的意义。
资源：●图标资源也需要遵循统一的规则，因为不同的图标代表不同的意义。
例如：我们用图标来表示保存，因此我们在整个系统中只要涉及到保存的话，都应该使用同一个图标，不论是用在工具栏上还是在菜单上，还是在按钮上。
●图标、图像应该很清晰的表达出意思，遵循常用标准，或者用户机器容易联想到的物件，绝对不允许画出莫名其妙的图案。
●鼠标光标样式统一，使用系统标准。
注意：本系统中不采用窗体做进度条，对于按钮后，鼠标变成沙漏形状，执行完成后，鼠标变回。
字体：●系统中中文一律采用标准字体“宋体”，英文一律采用标准Microsoft Sans Serif ，除登录界面和图标中的特殊字体用图片实现，原则上不考虑特殊字体（隶书、草书等，特殊情况可以用图片取代），保证每个用户使用起来显示都很正常。
●字体大小统一规定，MSS字体8磅，字体为10磅，字体颜色一般采用系统默认颜色。
●所有控件尽量使用大小统一的字体属性，除了特殊提示信息、加强显示等例外情况。
文字表达：●使用统一的语言描述，提到同一个概念时，用相同的术语描述。
例如一个关闭功能按钮，统一描述为关闭，避免使用返回、退出描述。
●通常情况下，每个窗口应该有一个唯一的标题，和触发它的菜单或按钮命令相对应。
●在提示信息中多用“您、请”等礼貌用语，不要用对用户来说晦涩的计算机用语，杜绝错别字。
●断句、逗号、句号、顿号和分号的用法，提示信息比较多的话，应该分段。
●错误消息对话框有仅仅指出问题，还要提供解决问题的建议。
控件选择：●不要随意使用控件，控件功能要专一，风格统一。
如果没有好的控件，则使用标准控件。
●同一类型的控件操作方式相同，避免出现一个控件双击可以执行某些动作，而同样的控件，双击却没有任何反映。
●一个控件只做单一功能，尽量不复用。
控件布局，窗口不拥挤，按功能组合控件●屏幕不能拥挤，也不能太松散。
●整个项目，尽量采用统一的控件间距，通过调整窗体大小达到一致，即使在窗体大小不变的情况下，宁可留空部分区域，了不要破坏控件间的行间距。
●文字和文本框一般采用左对齐方式，如单选文本框前的标签提示，使用左对齐加冒号；数据列表表头文字和容，也采用左对齐。
文字和文本框中的文字水平中对齐。
横排按钮，最右边的一个与上面的控件右对齐。
●为了使界面不出现跑版或者难看的局面，解决方法是固定窗口的大小，不允许改变尺寸。
5.数据库评审设计数据库之前（需要分析阶段）●数据库选型的考虑●必须对所有的实体关系绘制出关系图及相关说明，创建数据字典和ER图。
表设计●标准化和规化：数据的标准化有助于消除数据库中的数据冗余。
第三式（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的，但要有充公的理由。
●数据驱动：采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
字段设计●每个表中都应该添加的3 个有用的字段（dRecordCreationDate，在VB下默认是Now()，而在SQL Serve下默认为GETDATE()；sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER；nRecordVersion，记录的版本标记），有助于准确说明记录中出现null 数据或者丢失数据的原因●对地址和采用多个字段：描述街道地址就短短一行记录是不够的。
Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。
还有，和地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
●使用角色实体定义属于某类别的列：在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
●选择数字类型和文本类型尽量充足：在SQL 中使用smallint 和tinyint 类型要特别小心。
比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。
假设客户ID 为10 位数长。
那你应该把数据库表字段的长度设为12 或者13 个字符长。
但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
●加删除标记字段：在表中包含一个“删除标记”字段，这样就可以把行标记为删除。
在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
选择键和索引●键设计4 原则：为关联字段创建外键、所有的键都必须唯一、避免使用复合键、外键总是关联唯一的键字段。
●使用系统生成的主键：设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。
这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。
采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
●不要用用户的键(不让主键具有可更新性)：在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。
通常的情况下不要选择用户可编辑的字段作为键。
●可选键有时可做主键：把可选键进一步用做主键，可以拥有建立强大索引的能力。
●逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。
考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
●大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
●不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
●不要索引常用的小型表：不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。
对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
其它●防止数据冗余、防止更新异常、插入异常和删除异常！●每个表存在主属性，而且所有的属性都是依赖于主属性！●如果表的数据记录少，如不会超过上万条记录，可以考虑不建索引，数据记录多时，必须建索引。
特别是上百万或者几千万条记录。
●如果表的记录总值会超过500万条以上，考虑建分区。
数据库文件大于4G时，考虑采用多个文件组，存储在不同的磁盘上，以便于用户对某些数据进行精确备份。
●10G以量数据存储时，考虑对过去的数据采用数据压缩技术。
●考虑表与表之间的关联最好不要超过三层。
●对于大数据量的表只允许关联两个相关的小表，小表记录条数不允许超过1万条记录。
●数据库设计时对于统计数据，要有统计表，避免发生查询时为了获取一个数值对几十万条记录进行统计计算的情况，如年统计、月统计等。
好的数据库设计，必须有一定的数据库知识的人来操作，才会发挥好的性能。
操作数据库知识考察的要求：●编写SQL语句、视图、存储过程需要考虑不同的语句写CPU、存的影响，优化使用查询、联接、分组等。
●对常用的数据如left join、Right join、join、union和 union all 的用法熟悉、理解其数学的原理。
●在编写与数据库相关的操作时，控制并发数、尽可能地不要去查询冗余的数据。
●大量的操作尽量在程序完成，易于控制存或者CPU占用。
