技术评审
在工作中，我们经常可以听到以下的声音：
“我们不进行评审，是因为我们项目比较特殊，没有时间……”。
“我们的项目已经进行了测试，不需要再进行评审了”。
“评审都是在走过场，没有效果……”。
业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。
Why-为什么要技术评审？
测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示：大多数企业的产品开发中，2/3的缺陷都是在需求和设计阶段引入的。因此，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。
缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。
案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。
评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！
What-什么是技术评审？
测试和技术评审都是有效的质量控制手段，但也有明显的区别。 类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求
这是该阶段的一个最重要的任务.以下为获取用户需求需要执行的活动（如图1所示）。
● 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
● 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
● 需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：
⑴对于用户提出的每个需求都要知道“为什么"，并判断用户提出的需求是否有充足的理由;
图1 获取用户需求的活动
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；
⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员.大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：
⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；
⑵使需求符合系统的整体目标；
⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
设计人员（TS、DAR）
1.如何进行选择技术解决方案?(TS SP1.1/TS SP1.2/DAR)
回答：
1. 项目组依据组织的决策流程，在项目开发过程中，进行了一次决策分析过程的实施，对….进行了决策。首先制定了决策分析计划，再定义了具体的解决方案，再依据组织给出的决策因子和权重对方案进行打分，选择得分最高的方案，我们最终方案是XXX。
2. 决策的过程是：
a. 依据组织给出的决策因子：如：易用性/灵活性/复杂度/额外硬件投资/执行效率/安全性/可用性/可伸缩性/可维护性/成本节约
1. 依据决策因子的决策评价准则进行打分：如：易用性(1-10)
b. 项目中选择的是加权打分法，利用加权打分方法我们通过：评审、测试、模拟（仿真）的方式对每个因子的选择标准进行分析，最终决定每个因子的最终得分，及方案的最终分数，最终选择分数最高的方案
2.设计输出哪些文档？请说明这些文档是如何进行设计的？(TS SP2.1)
回答：
1. 依据《设计规范指南》按照模块进行设计，如果模块太大可以将模块分成若干个子模块分别设计，在我们的设计中可以根据项目情况将设计划分成概要设计、详细设计、数据库设计、接口设计等几部分
2. 整个系统分解为子系统（概要设计）和模块（详细设计），并确定每个功能模块的输入、转换和输出数据流，并考虑各方面数据接口、存储方式等，同时细化数据结构化设计，完善数据字典以确保系统能获得所需的输出结果，从而实现系统的构架设计。
3. 接口设计：根据界面逐个描述界面上每种涉及到业务逻辑操作的输入输出参数信息以及操作的处理步骤，设计模块的接口与属性，说明函数功能、输入参数、输出参数、返回值等（包括内部接口和外部接口）
4. 数据库设计：其中数据库脚本部分内容必须提供，其它部分内容可以在总体设计中统一描述，也可以提交单独的数据库设计说明文档，包括数据库脚本（包括创建表、视图、存储过程、触发器、序列号等数据库对象的SQL语句）
软件开发项目管理及实施方案
第1章 项目立项与规划 ................................................................................................................. 4
1.1 项目背景分析 ................................................................................................................... 4
1.2 项目目标与需求 ............................................................................................................... 4
1.3 项目可行性研究 ............................................................................................................... 5
1.4 项目规划与时间表 ........................................................................................................... 5
第2章 项目团队组织与管理 ......................................................................................................... 6
2.1 团队组建与职责分配 ....................................................................................................... 6
