Software Engineering

如果软件版本更新时修改了某些表的结构，一定要注意处理历史数据的问题

◇ 可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 　　◇ 项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 　　◇ 软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 　　◇ 概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 　　◇ 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 　　◇ 用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 　　◇ 测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 　　◇ 测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 　　◇ 开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 　　◇ 项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 　　◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 　　◇ 软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 　　◇ 软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。

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过程：处理和实现在项目进展中产生的各个产品的变更

    今天同事小Q提出：除了开发环境和生产环境，再建一个测试环境。    开发环境散落在各开发人员的电脑上，如果直接在开发环境上进行测试，一些person-specific的东西可能会影响测试的准确性，于是就需要建一个测试环境，与开发环境相比，它的特征是消除了person-specific的特征，与生产环境相比，它不用承担生产上的风险    测试环境还有一个用处。向开发中的外部系统提供服务时，直接用生产环境进行联调是不合适，用测试环境就没什么风险了。因此，我们的产品上线后，测试环境仍要与生产环境长期共存、并保持开放状态

可以采用这种模式：     1.文章修订记录中有“确认人”、“确认时间”字段，和“修改人”、“修改时间”字段一样重要     2.除了“确认人”和“确认时间”，还可以有一个字段：“此次修改内容的颜色”，若不同的修改同时存在，可以通过颜色来区分。一般情况下，这次修改用“红色”，待确认后改回“黑色”即可；但如果这次用了“红色”，而在这次修改确认之前，又有了新的修改，则新修改可以采用“蓝色”，对方确认了红色修改，则将红色部分改成黑色，对方确认了蓝色修改，则将黑色部分改回黑色，以保证不会混乱     3.一般情况上，在本次确认之前不会提交新的修改，这时只用一种颜色代表新的修改就可以了     4.重要的部分可以用粗体、斜体表示，但不能用颜色表示，以免与“新修改部分”混淆     5.接口模式约定了一定要说到作到，要不然就会造成更大的混乱

文档命名公约 ——————————————————————————– 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 …

文档命名公约———- Read More »

1.按四层体系结构组织：过程，阶段，活动，子活动（最小单元） 2.为本机构建立一个通用（标准）过程，在做具体项目的时候按项目需要对此过程进行裁剪。因此过程裁剪是一项重要的项目计划活动。 3.计划和计划的执行总是可以分开的，比如测试计划（用例）可以在编码前就写好。这样做的目的就是让计划和其他阶段可以并行执行

在编程时，开发人员倾向于认为代码肯定是对的，不可能错，不用做单元测试了，或者只做个正例测试得了 但实际上，臭虫就是在这种情绪下滋生的， 尤其是牵涉到账务计算的金融系统。 这是教训，应该考虑把“是否编写单元测试用例或代码”作为代码审核的一个考核点。

In software testing, a Build Verification Test (BVT), also known as Build Acceptance Test, is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. The build acceptance test is generally a short set …

Build verification test Read More »

Blocked代表你的测试仍未完成，因此不能说是"Not Run"，也不能说是"Pass"或者"Failed"