软件产品评审表

1.过程检查要素表配置管理过程√√√√设计阶段结束测试阶段结束软件过程审计报告SQA人员，项目经理，配置管理员软件质量保证过程√√√√验收阶段结束软件过程审计报告高级经理，SQA经理，项目经理2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。

2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。

3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。

4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。

5)软件过程检查打分的依据是“过程检查表”。

2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。

2)每个项目过程的得分M＝30 / N。

3)采用“过程检查表”，对各个过程进行检查和打分。

4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。

5)实际检查时，对“实施情况”一栏中每个条款进行打勾“”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。

6)每个过程的实际得分Bi=∑1x Bj。

7)每个过程的换算得分B=Bi /A ×M。

8)若某个过程发生多次z，则该过程得分B=(∑1z B)/z 。

9)项目的过程得分C=∑1N B 。

10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。

2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项,标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。

Design Review ChecklistArchitecture DesignGeneral:Does the architecture convey a clear vision ofthe system that can be used for furtherdevelopment?Is the architecture structured to support likelychanges?Does the architecture describe the system at ahigh level of detail? (No interface orimplementation details.)Does the architecture cleanly decompose thesystem?Is the architecture independent of theinfrastructure used to develop the system?Has maintainability been considered?No duplicate functionality in the architecture?Complete:Are software requirements reflected in thesoftware architecture?Is effective modularity achieved? Are modulesfunctionally independent?Does each module/class have anunderstandable name?Is each association well named?Is each association’s and aggregation’scardinality correct?Correct:Does each association reflect a relationshipthat exists over the lives of the relatedmodules/classes?Does the architecture have loose coupling andgood cohesion?1Detailed DesignGeneral:Does the design support moving to the next phase ofdevelopment?Does design contain proper level of detail?Does the design have conceptual integrity? (Qualitywhere the individual pieces all contribute to making alarger whole. Design consistency.)Will the design be easy to port to anotherenvironment?Have reusable components been identified?Is effective modularity achieved? Are modulesfunctionally independent?Complete:Is the class design consistent with architecturaldesign? (i.e., each class traceable to architecturalcomponent and no classes span architecturalcomponents)Does each class have an understandable name?Does each class define attributes, methods,relationships, and cardinality?Is each association well named?Is each association’s and aggregation’s cardinalitycorrect?2Correct:Does each class have a clearly defined purpose? Caneach class be described in a single sentence?Is a consistent naming scheme used for all classes?Are all attributes private?Are all method signatures specified including returntypes and parameters?Do all subclasses implement the "is-a-kind-of"relationship properly?Is there no duplicate functionality between classes inthe design?In inheritance structures, are all attributes and methodspushed as high in the inheritance structure as isproper?Are all polymorphic methods within related subclassesidentically named?Does each association reflect a relationship that existsover the lives of the related objects?Has error handling been specified?Is design detail amenable to implementation language?No hidden implementation details shown?Does design display high cohesion and low coupling?Consistent:Are each 0..* and 1..* relationships implemented withcontainers/collectors?Are each association’s cardinalities consistent(instantaneous vs. over-time)?Are the views provided by different modelingnotations consistent?Is a consistent naming convention used and followed?3。