1.项目的三要素：成本，进度，质量 2.项目成功的一个关键因素在于项目有一套过程 3.软件过程 = 一系列步骤 + 本开发机构所积累的经验 4.CMM 是一个 “过程体系” 5.过程越成熟，项目对开发人员的依赖就越少，项目就越好控制，实际结果就越好 6.CMM2的KPA关注项目管理，CMM3的KPA关注过程的制度化 7.要通过某级的CMM认证，就必须满足该级别及其以下级别下所有的KPA 8.SPP=立法，SPTO=执法 9.SQA != SQC(如测试)，SQL的目标是使质量活动有计划–遵循标准和过程 10.SCM是为了让文档和程序被标识，且更改受控制 11.CMM3的一个基本要求：标准过程必须很好地确定并成文归档 12.如何从以前的项目中获得经验教训？主要机制：过程数据库(CMM3)和过程能力基线(CMM4) 13.CM过程：处理和实现在项目进展中产生的各个产品的变更
到底是选择CMM还是CMMI主要基于以下几个方面进行考虑： 实施企业的业务特点： 如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。 实施企业对过程改进的熟悉程度： 如果企业已经实施过ISO 9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。 实施企业对过程改进项目的预算： 不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就经济很多。
FireFly类似于ClearCase，主要做版本管理，好像没其他的 http://www.hansky.com.cn/cn/resource/prod/pdf/FireflyIntro.pdf ButterFly类似于ClearQuest，“缺陷跟踪、建议处理、任务计划以及工时周报”。“建议处理”就是需求变更 http://www.hansky.com.cn/cn/resource/prod/pdf/butterflybrochure.pdf http://www.hansky.com.cn/cn/doc/butterfly/quickstart/index.html
这些管理平台有时候不能彻底相互区分，但实质上各不相同 1.需求管理。 如Doors 2.任务管理。 如XXX 3.项目计划与进度控制。 如MS Project 4.测试管理。 如Mercury，TestLink，可以将它与需求管理平台挂钩，即将用例与需求挂钩 5.缺陷追踪。这个东西常常与测试管理平台一起使用，或者自身就充当测试管理平台的测试执行部分。如Bugfree, Bugzilla
广义上对测试有三个传统的称呼，alpha、beta、gamma，用来标识测试的阶段和范围。 alpha 是指内测，即现在说的 CB，指开发团队内部测试的版本或者有限用户体验测试版本。 beta 是指公测，即针对所有用户公开的测试版本。 然后做过一些修改，成为正式发布的候选版本时（现在叫做 RC – Release Candidate），叫做 gamma。
测试管理过程 1.Define Test Requirements 2.Develop Test Plan 3.Execute Tests 4.Track Defects
Blocked代表你的测试仍未完成，因此不能说是"Not Run"，也不能说是"Pass"或者"Failed"
文档命名公约 ——————————————————————————– goto推荐 [2005-6-6] 出处：internet 作者：未知 项目中涉及到的所有文档可以被命名为 <项目名称>_项目名称/项目版本编号>_相应工作过程名称>_文档版本编号>等样式。例如： Pt_Louise_ModuleA_SRS_1.1.doc Pt_v1_ModuleA_SPP_0.1.doc Pt_ModuleA_SCM_1.doc Pt_ModuleA_SQA_2.1.doc Pt_ModuleA_Functional Specification_1.doc Pt_ModuleA_Detail Level Design_1.doc 下划连线“_”用来分开各名称域，但它不是必需的。 相应工作过程名称的简称（例如 SPP，SRS）也不是必需的，但如果要使用，应该遵守下面表格中的标准。 软件构成设计文档 （Component Design Document） CDD 具体设计文档 （Detail Design Document） DDD 软件功能设计文档 （Functional Design Document） FDD 软件功能说明书 （Functional Specification） FS 手册 （Handbook） HB 系统集成测试计划 （Integration Test Plan） ITestPlan 系统集成测试报告 （Integration Test Report） ITestRep 组间协作文档 （Intergroup Coordination …
◇ 可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 ◇ 项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇ 软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 ◇ 概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 ◇ 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 ◇ 用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 ◇ 测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇ 测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 ◇ 开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇ 项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 ◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 ◇ 软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 ◇ 软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。
看了一家软件公司竞标时提交的解决方案，觉得不错。我概述一下它的结构，以后我们可以仿照着写。 1.建设目标。 勿废话，直接指出你的方案可以带来的几个方面的好处 2.业务流程。简明地概括最基本的功能需求，最好以图形方式描述。这样甚至可以帮助客户理清他们的需求。我看到的方案中用了一种矩阵式的描述方式，x方向为流程的阶段，y方向为流程的参与者（子系统、外部系统、人类角色），效果非常不错 3.总体规划。将业务流程中提到的外部系统、子系统、角色提取出来，描述一下它们之间基本的交互，确定各自的边界。仍以图形方式为佳 4.重要功能的细节。提出你的一些精彩的解决方案，一些贴心的东西，可以加分不少 5.辅助功能及非功能需求。如性能、可靠性、易用性、权限、日志等 6.架构设计。包括逻辑架构和物理架构。前者多以“层”组织的方式描述，如表现层、业务层、持久层，每层中的子系统以及跨层的子系统等；后者就是服务器，交换机，路由器等