迷失的精灵
第1楼2008/11/15
需求与设计评审角色
1．角色角度构成
需求与设计评审需要的角色首先要有评审组长，即这个项目的整个评审工作的组织者，需要有管理、评审及会议主持等工作经验。
其他除了文档的作者及记录人员之外，主要的角色就是评审人员，这一角色可以由具有以下不同角度知识技能经验的人员构成。
① 项目管理专家：具备项目管理知识与经验，主要是为了检查需求或设计对项目管理的可能影响，现行项目管理工作与这些文档中所提要求的符合性。
② 质量管理专家：掌握过程与文档相关规范，这些规范可以是行业内部通用的，也可以是企业内部制定的。
③ 软件工程专家：掌握软件工程、需求和设计建模方法，能够对文档中表达方法的正确性进行判断。
④ 相关行业专家：具备丰富的行业业务经验，一个好的系统分析员也应该是好的业务专家。对于需求评审来说，有客户或所建系统相关行业专家的参与是至关重要的。
⑤ 企业资产库管理者、中间件和平台专家：“永远别重新发明轮子”，软件开发一般是将系统建立在某种平台之上或者使用某些中间件。而每个企业针对自己使用的开发方法都会有一定的积累，如类库、系统框架、用户管理、系统管理、信息代码管理和界面管理等都是可以复用的资源，不需要从头开发。
⑥ 相关系统开发人员：在后面提到的前后左右相关的项目成员。
⑦ 内部后继环节人员：包括编程语言及工具专家／数据库专家、界面设计师／美工和测试人员和维护人员等，他们一方面对需求与设计文档进行熟悉；另一方面也可以检查文档是否可以被理解，也可以其知识和经验进行判断。
⑧ 某类硬件专家：与硬件系统较密切的软件开发项目，如电梯、手机、机器人和驱动等，需要对这些硬件的性能和接口较熟悉的人员。
⑨ 产品经理、类似产品和竞争对手分析人员。
⑩ 最终用户、客户和行业标准制定人员。
全球化专家／用户所在国文化专家：对外包或外销软件开发项目而言。
以上只是提供一个较为全面的角色选项，不是每种角色都有一个人，而是一个人可以兼多个角色。评审组成员的构成也不是一定都需要里面的所有角色，具体项目要具体考虑，选择其中必要的角色进行搭配。
2．角色构成因素
评审人员的选择是评审效果的关键，需要考虑以下因素。
① 项目重要性：项目重要性是决定角色构成的最重要的因素，评审角色的构成因素首先要根据项目的重要性而定。这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。
② 项目复杂度：项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。
③ 项目组成员的能力成分和水平：评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。
除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。Bhuvan Unhelker在《基于UML的软件项目的过程质量保障》中说：“要保持质量职能的独立性，只有通过指定项目以外的人员来承当角色才起作用”，测试工作也有“独立性”的要求。
应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。
3．基本角色职责
① 评审组长：制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。
② 评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。
③ 文档作者：按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
④ 记录人员：评审会议中记录评审人员提出的问题及相关讨论。
⑤ 项目经理：制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误的改正时间。而且评审安排及结果与所有项目成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进项目质量。
迷失的精灵
第2楼2008/11/15
需求与设计评审的层次
1．层次管理概览
① 过程规范：是否符合过程规范。
② 文档规范：是否符合文档模板规范。
③ 文档语法：是否使用通用术语，是否符合某种建模标准或分析设计方法。
④ 文档语义：是否表达清晰且正确。
⑤ 文档逻辑：是否考虑周全，符合相关行业标准。
⑥ 文档美学：是否最佳表述。
⑦ 结果优化：是否最佳分析设计。
过程规范和文档规范主要保证规范性，文档语法和文档语义主要保证可读性，文档语义和文档逻辑主要保证正确性，文档美学和文档优化主要保证最优性。
2．质量层次模型在评审中的作用
质量层次模型在评审中的作用主要体现在以下几个方面。
① 可以使评审工作有层次并有阶段地开展，管理层次按照规范性→可读性→正确性→最优性的方向逐步提高要求。
② 可以用于确定评审人员层次结构，每个评审人员比较擅长或适合哪个层次的评审可以在评审工作中进行考察并确定。
③ 可以按层次建立企业评审专家库，即通过以往评审工作的考察建立。
④ 可以按层次合理选拔评审人员，即从企业评审专家库中选拔。合理搭配，确实保证多角度和多层次的评审。
⑤ 可以为个人职业发展方向提供参考，个人选择比较适合自己的层次作为努力的方向。
3．评审的层次
① 过程规范：是否符合过程规范、是否按照计划提交、是否按时经过评审、是否准时发布（注意提交时间与发布时间的区别），以及评审的流程是否规范。
适合的评审人员：SQA。
② 文档规范：文档成果符合企业或业界已经制定的文档模板规范。企业，甚至行业应当制定统一的文档规范，形成一个文档约定和规则，以统一文档内容与风格。
适合的评审人员：SQA。
③ 文档语法：文档成果正确使用通用的方法与术语并符合软件工程相关的技术标准，这里所说的语法包括自然语言的语法和建模语言的语法。
适合的评审人员要求：精通软件工程、分析与设计方法、建模工具和相关标准。
以上3点站在规范性角度，是进一步评审的基础（基本可读性），可采用非正式评审。
④ 文档语义：文档成果表达清晰、无歧义，可以反映系统目标。所有质量合格的文档（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。文字与图表应当互相补充说明，以更加清晰。让别人看得懂，看完后知道下一步该怎么做。
适合的评审人员：行业业务专家，有经验的系统分析与设计人员、高级程序员和测试工程师。
⑤ 文档逻辑：主要体现需求与设计正确性、一致性，无遗漏、多余或错误。前后左右考虑周全，不同文档之间、文档与行业标准之间、同一文档各成分之间不互相矛盾，清晰说明相关部分之间的关系，特别是要符合相关行业的业务标准规范。
适合的评审人员：行业业务专家、产品经理、有经验的系统分析与设计人员和测试工程师。
上面几个层次已经保证阶段成果基本满足质量要求，后面所提的两个层次是在此基础上进一步的优化。
⑥ 文档美学：文档成果能否表述得更好一些，文字、图表是否能更加均衡和完整。需要追求平衡的美，每个组成部分应该大小适中，可解读并可变更。平衡有多个方面，如排版次序更加合理、文字、图形更加精炼并更易理解等。
适合的评审人员：系统分析与设计专家，以及建模工具专家。
⑦ 结果优化：通过检查判断文档成果（如项目计划、需求规格及设计方案）是否还有改进的空间，以便更加方便地进行项目管理、降低成本、加快进度、提高质量并减少风险，尽可能达到最佳方案。任何一项设计都可以有许多不同的方案，通过“方案优化”选定一种最好的方案。
适合的评审人员：系统分析与设计专家、项目经理和产品经理。
4．评审级别判断因素
① 项目团队技能水平：相对于使用的技术，对团队成员来说是比较熟练的还是新技术？软件技术不断发展，使用新技术是常见的事情。
② 项目对公司业务的影响程度：所开发的软件是否有较好的或广阔的市场前景，或者对与客户的关系有较大影响？
③ 项目对用户的重要程度：是否为用户方的“一把手”工程？
④ 人员投入及进度的紧张程度。
⑤ 项目规模、项目环境和项目的各项要求。
⑥ 项目目的是赢利还是科研试验。
⑦ ROI投资回报率：投资回报率高，自然得到高度重视，各项投入也会增加。评审力度自然也要加强，以确保预期的投资回报率变成真实的投资回报率。
⑧ 项目工业化分类，常规的可分为以下几类。
— 产品研发型和定制工程型：这是可以比较正规地按照软件工程方法组织开发的项目。
— 半产品半定制型：这是比较常见的开发类型。
— 产品升级型和定制升级型：随着公司的发展，用户的业务需求也不断发展，版本也会不断更新。而留住老客户成了主要任务，服务性质的工作会越来越多。
— 装修型、侍从型和打靶型：这几个都是典型的“四边型”项目，即边做、边提需求、边改、边完善。摸着石头过河，逐渐满足客户的需求或逐渐靠近项目的目标。
— 民间工艺型：个人利用“业余”时间开发小软件，可以随意地发挥个人的创造性。
当然，以上的分类不一定完整，各类之间也只是“量变到质变”的关系，还有其他不同的类型，不过都可能变成四边型。
最常见的是类型的不断演化，形成混合型。
混合型1：研发→定制→装修→侍从→升级。
混合型2：定制→研发→装修→侍从→升级。
不同的类型对评审的要求显然是不同的。
赛默飞实验室产品焕新计划有奖调研！
【七月征文】不一YOUNG实验“猿”
报名开启：ICS2024第十三届光谱网络会议！
推荐收藏！盘点中药材及饮片检测解决方案
