软件产品发布的必要条件.docxVIP

PAGE 1 PAGE 1 软件产品发布的必要条件  如何知道项目已经完成（必需要定义一些完成的准则）何以知道已经完成？  当产品已经足够好的状况下，可以确认是否已经完成。  “足够好”：是指产品已经具备一些可接受的综合属性，如功能、质量、时效性、客户价值、竞争力以及支撑的基础设施已经预备就绪。  客户对质量的看法主要取决于牢靠性（持续运行无故障）和性能（操作的响应时间）  内部对质量的看法主要设计如下方面：软件在将来的可修改性、可维护性、文档的可理解性等  如何定义产品发布准则？  发布准则必需要与成功准则相对应，没有放四海而皆准的发布准则，要确保项目取得最终的成功，反映产品能够上线发布的指标都必需要有一定的可信度和可测度。  假如指定了不符合项目业务目标的宽松的发布准则，可能会造成一种一定会可能会取得成功的假象。  一些宽松的发布准则：广泛的客户群体曝光率，“很高的客户满足度”  某些模棱两可的措辞：可接受的、足够的、恰当的、广泛的、精确地、高的、改进的、低的、合理的、健壮的、精确无误的和有效率的。这些措辞要尽量避免使用。  发布准则必需要满意：  Specific【明确的（不是空泛的）】  Measurable【可度量的（不是定性的或主观的）】  Attainable【可实现的（不是一对不可能实现的目标）】  Relevant【相关的（与客户要求和业务目标相关联）】  Trackable【可跟踪的（在整个项目过程中可以进行监控）】  制定准则时：  专心考虑不同项目干系人对团体的想法和意见，避免冲突和分歧  考虑用户提出的验收标准  于关键用户代表进行充分沟通  出现冲突时，全体团队成员必需要工作在共同的目标集合上，并做出适当的折中推断。  可能的发布准则项：  1)缺陷  质量是一系列复杂和多维度的产品特点的集合。发布一个不成熟且存在许多缺陷的产品会导致很高的运行成本、用户的绝望、很差的产品评价、过高的维护成本、产品退货甚至法律纠纷。作为质量的指标之一，可以对开发和测试中发觉的缺陷的数量和类型进行跟踪。  假如质量是项目的一个成功准则，可以参考如下与缺陷相关的发布准则：  在一个四级的缺陷跟踪系统中，不存在未解决的最严重的1级或2级缺陷。在过去的X周内，未解决的缺陷数量持续下降，同时估算的遗留缺陷数量是可以接受的（可以采用缺陷模型来进行预估）  在编译器中、源码分析与运行时分析中所报告的全部错误和警告都得到了修正。  前一发布版本出现的问题都已经得到了修正，在修复过程中也没有引入额外的缺陷。  2)测试  大多数软件团队都特别依靠不同类型的测试来发觉缺陷，可以通过查看估算的未发觉缺陷数量是否处在可接受范围内，或者在预设的测试时间内并没有发觉新的缺陷时是拒绝定停止测试，一些主要的发布准则如下：  代码编译、构建和冒烟测试是否在全部平台上通过；  综合测试和系统测试100%通过  特定的功能通过了全部的系统和用户验收测试（如正常流程和相关的异常处理流程在普遍的用例中测试通过）  测试计划中涵盖的全部记录在案的功能需求的测试用例都得到了执行  达到了预先设定的代码或需求（如功能需求、测试用例流程或者产品属性）  综合考虑测试和缺陷相关的因素，一位学者认提出的产品发布准则：  完成了掩盖100%功能点和80%的回归测试  不存在严重等级1和等级2的缺陷；  已知的遗留缺陷密度少于每千行代码0.5个缺陷；  每1000小时的测试工作发觉新缺陷的数量少于40个  发觉缺陷的平均间隔时间少于100小时  完成了压力测试、配置测试、安装测试、本地化测试、可用性测试和傻瓜用户测试。  3)质量属性  质量属性是另一只哦能够用于描述产品德为的思维方式，这些属性包括牢靠性、安全性、完整性、可用性、便携性、可维护性、高效性、健壮性和交互型等。一些相关的准则是：  在全部的平台上的定量性能目标得到满意  牢靠性目标得到满意  相关公司的安全策略和需求得到了满意  特定的条件已经符合，可以使得产品通过必要的评审或者审计  4) 功能  在即将发布的产品版本上，全部的承诺的高优先级需求已经实现并能正常工作  满意特定客户的验收的标准  满意全部非健全人士的可访问性需求  假如需要软件在不同语言环境下运行，全部本地化与全