微软专案求生手册备忘录
最粗糙的软体开发程序 1. 2. 3. 4. 5. 6. 讨论要写出怎麼样的软体 写出些程式来 测试程式,找出缺失 除错,找出错误根源 修正错误 如果专案还没完成,回到第一步
阶段里程碑 (Milestone) 积极的进度追踪.阶段的规划必须为进度追踪奠下基础,进行进度追踪是建立一 详细的里程碑,始专案主管可以用来标示阶段中已完成的进度. 阶段里程碑是阶段开发人员与其他专案成员必须经常满足的目标,至少以每一星 期必须完成一个阶段里程碑的频率进行,每个里程碑都是二分性的,他只有完成 与非完成两种状态,没有所谓的 90%完成. 阶段里程碑帮助团队将焦点放在最重要的工作上,如果只规划长程里程碑,专案 进行中就很容易到处浪费一天,两天或是一星期,两星期的时间.人们花时间在 有趣或是看起来有生产力实际上对专案推动没有什麼帮助的事情上.
问:专案是怎麼慢了一年才完成的 答:每天都慢一点时间 -- Frederick P. Brooks
专案时间管理分类范例
类别
管理
活动
规划 处理顾客/使用者关系 处理更动 停工时期 人力准备 建立开发程序 检讨开发程序 修订开发程序 对顾客或团队成员进行开发程序教育 建立规格 检讨规格 修订规格 回报规格中的缺失 建立雏形 检讨雏形 修订雏形 回报雏形中的缺失 建立架构 检讨架构 修订架构 回报架构中的缺失 建立设计 检讨设计 修订设计 回报设计中的缺失 建立实作 检讨实作 修订实作 回报实作中的缺失 调查/增添元件 处理增添元件 测试/检讨增添元件 回报增添元件的缺失 自动化版本建立
行政 程序开发
需求开发
使用者介面雏形
架构
细部设计
实作
增添元件
整合
建立维护版本 建立测试版本 建立发行版本 系统测试 规划系统测试 建立系统测试说明 建立自动化系统测试 执行人工系统测试 执行自动化系统测试 回到系统测试中找到的缺失 准备跟支援各 alpha, beta 版或者各阶段发行版本 准备跟支援最后发行工作 收集管理资料 分析量测资料
软体发行 资料表格
每日整建 (daily build) 与冒烟测试 每日整建: 开发人员将自己的程式码与开发专案主体原始码比较,找出与最近其他 专案开发人员新增或修改的程式码中的冲突与不协调处,然后将自己修 改的程式码与专案主体原始码合并,经由自动化原始码控制工具处理 (Visual SourceSafe, CVS, Team Source). 建立与测试个人专案版本,确定新实作的功能如期运作无误. 冒烟测试 名词来自电机工程界,方法为将机器打开,看机器在运转过程中会不会 中途突然冒烟烧掉. 执行冒烟测试,确定新的程式码不会故障 纪录归档:将自己撰写的程式码加到专案主体程式码中 产生每日完成版本 进行冒烟测试 :整个团队以冒烟测试来评估目前的完成版本是否稳定的足以 通过测试 立刻修正任何问题!如果发现任何错误,通知让程式故障的程式员(通常来 自最近新增或修改的程式码) ,让开发人员立刻修正问题,修正目前版本的 问题应是最优先考量. 在每日整建与冒烟测试中,找出让完成版本坏掉的程式师,确保他们立刻修好坏 掉的程式码.小型专案中可由一个品质保证人员兼任之,大型专案必须有一人或 甚至是一组人专职进行每日整建的工作. 分辨出问题来自旧的程式码或是新的程式码! 冒烟测试应该随著专案进展而时时更动,以更上软体开发的脚步,因为冒烟测试 是天天进行的,所以常常利用自动化处理,冒烟测试内容应该涵盖足够的软体功 能项目测试,以确认每天产生的版本是否真的可以通过测试评估,如果软体稳定 度不够,冒烟测试应该让软体当掉.
测试哲学 测试经常是软体发展中的重要关键,因为直到软体大部分完成之前,没有人规划 进行测试工作,在此状况下就不可能快速做好完整的测试软体动作,以致某些测 试过程被忽略掉,产品带著许多不确定的缺失而推出 因此真正的软体测试应该是以密集的步伐伴随著软体发展而来,测试项目应该比 软体实作本身早一步或是同时进行.
软体发行 要不要发行软体是个危险的问题 ,答案就卡在早点发现低品质的软体跟晚点发行 高品质的软体之间的夹缝中. 缺失数量:这类的缺失追踪,让人能适度了解并操控发行软体之前还有多少 工作要做,像是这样的报告 "2 个重要缺失,8 个严重错误,147 个表面缺 失" 藉由每周出现的新缺失和解决掉的缺失数目,就能得之距离专案完成的 日子还有多远 缺失密度测试:另一个简单的判断方法是,检查程式的缺失密度,即每行程 式码的缺失数目,例如 App 1.0 拥有 100000 行的程式码,若被发现有 700 个缺失,即表示每一千行程式码有七个缺失,在下一版的 App 2.0 中增加了 50000 行程式码,这此找到 475 项缺失,每千行程式码就有 9.5 项缺失.现 在公司专案 App 3.0 正面临发行前夕的测试,新的版本多增加 100000 行程 式码,发行前找到 600 项缺失,也就是每千行程式有六项缺失.除非有任何 更好的理由说明团队开发的过程已经获得改善,不然根据经验我们应该期望 每千行程式有 7~10 项缺失,也就是说我们得在发行前再找出 650~950 项缺 失,如果我们预期消除 95%的缺失的话. 缺失分堆 缺失播种 缺失模型化:对软体缺失的处理状况而言,没有坏消息就是真正的坏消息, 如果专案到了后期还是只有少数几项缺失被发现,人们会自然倾向於认定终 於完成一个几乎没什麼缺失的程式,但事实上没有坏消息是因为测试做的不 够,而不是开发团队绩效优异.

下一页