敏捷开发日常跟进系列之一：燃尽图（上）
这个系列将涉及燃尽图（Burndown Chart）、故事板（看板）、每日立会等内容，描述在计划会之后，评审会之前，敏捷开发团队内部产出与产品经理和项目经理的各种活动。
日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。
在这个系列之前，还应该有一个敏捷计划系列，描述敏捷开发的从版本规划到计划会估算的详细内容，未来将会补上，当前可以参考2.29版的《火星人敏捷开发手册》，有5页与其相对应。
燃尽图
燃尽图Burdown Chart也叫燃烧图，是罕见的敏捷度量，以至于每当有人问起“敏捷中有度量吗”的时候，第一反应就是它。
燃尽图的全称，应该是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图。
图中左侧460是迭代开始的第一天，所有故事的未完成时间相加为460天，而在最右侧则表明在第17天，所有故事的剩余时间相加变为0，也就是所有故事都完成了。
为什么总和会递减呢？因为每个组员每天都要汇报一件事情：当前正在做的故事，还剩余几天，如果昨天剩余3天，今天剩余2天，那么就为燃烧图贡献了1天的进度。
由于可能出现“昨天剩余3天，又工作了一天后本以为会只剩下2天，结果感觉可能还要3天（甚至变成5天了！）”这种情况，所以燃尽图常常有一些起伏。
燃尽图的“指纹”
图中的燃尽图尽管有一些起伏，依然是属于比较完美的燃尽图。实际上每个团队完成迭代的过程差别很大，常见的情况包括：
先鼓起后落下
原因是计划会以常常漏掉一些事情，所以开工后不但不燃尽，还发现了很多新的任务。
先完美燃烧，然后突然停止燃烧
一种很常见的情况，如果任务划分太粗，比如长达10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的时候，哎呀，好像搞不定了”。
先缓慢燃烧，然后到快燃尽的时候剩下一堆没完成的任务，被推迟到下个迭代
之前提到过敏捷开发的MoSCoW方法，有些故事是次要的“可以不做的”，所以这种燃烧图也很常见；但是常常有团队没有使用MoSCoW方法，只是被动地发现有些故事没有完成。
……
为了改进这些不完美，有些团队设置了一些度量项来改进燃尽图的结果，比如“迭代按时燃尽的次数”“剩余故事占总故事的比例”……
其实不用因为燃尽图的不完美而伤脑筋，在般若敏捷的“无住”中曾经提到，这些方法都非我们的目的，而只是一个中间的工具，因此为了完成我们的最终目的，这些工具和方法都可以灵活变通，而不要追求工具和度量数据本身的完美。
但是，迭代的最终目的到底是什么呢？有哪些“灵活变通”可以应用在燃尽图中呢？且待下回分解。
敏捷开发日常跟进系列之二：燃尽图（中）
迭代及燃尽图的目标
燃尽图的目标是完成迭代的目标，迭代的目标是什么呢？
1. 按产品经理的要求，交付计划会中计划的用户故事
2. 尽量完成1
之后还会看到，这个定义还有狭隘之处，在系列后面的文章中会提到。
为什么燃尽图不能直接地达成这个目标？潜在的问题包括：
1. 如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有故事（重要和不重要的）的质量，换取了进度。
2. 如果燃尽图未按时完成，有可能不是一个故事没有完成，而是所有故事都剩下点活没做完，导致所有故事都无法交付。
3. 如果燃尽图未按时完成，没有完成的故事中，有可能包括了极其重要的一些。
只从燃尽图的形态看，是无法提前识别这三者的，也就因此带来了很多的风险，到迭代的末尾让人大吃一惊。
怎么办呢？
“阶梯燃尽图”
之前听过这个方法，但是刚才在网络上没有找到图片。
方法就是在每个故事完成的时候才把整个故事突然剪掉，从而形成阶梯状。
阶梯状燃烧图的缺点也很明显：刚开始的时候很难看到有燃尽，甚至那些向上拱起的弧形也被掩盖了，日后回顾时，一些细节也很难记起来。
所以一种解决方案，是把普通燃尽图和阶梯燃尽图混合使用，就是同时画两条线。
“跟进图”
跟进图是一些大型团队的创造，由于团队巨大，所以不能指望在迭代的最后用2小时评审完所有工作，所以常常是做完一个评审一个，这就要给每个工作分配一个“跟进人”，他隶属产品部门，没事就盯着“跟进图”看看有没有自己关心的工作做完了。
在为一家游戏公司提供咨询的时候，他们一款产品的团队人数高达88人（另一个甚至到了200人），墙上就用手绘制了一幅巨大的跟进图，每天更新动态，甚至直接在纸上画上小图标，每月画满了，就重新打印一张。
下面这张，是火星人中的跟进图。
图中绿色粗线，就是传统的燃尽图；
每当一个故事完成，就会有一个蓝色的标记及完成故事的名字，从而提醒跟进人进行现场预评审；如果长期没有故事完成，燃烧图却还在燃烧，就肯定出现了之前说过的问题了。
右下部分还有一个暗红色的细线，是“溢出时间”，就是超出预期的工作的时间，表明这段时间出现了新的任务；新任务出现的太早不好，因为一般在迭代前期都先完成最重要的故事，不应该引入新任务；但在后期随着最重要的故事完成、评审、因不满意而返工，团队会倾向于把最重要的任务更好地完成，而非草草地把所有故事都凑合完成，在产品研发中，这往往是更能提升产品价值的。
一家叫做广联达的公司在实践中把溢出时间作为负数倒着画，称为“基线下沉”，就是说要去的地方不是0了，而是那个负数，是一个类似目的的很好的实践。
我试了一下也不错，就是图表会变高，显示起来不方便，所以还是改了回来。
这样的跟进图看起来已经很强大了，但是还有一些问题没有解决：
1. 有哪些故事正在做，还没有做，已经开工了但没完成……？
2. 最后剩下了哪些故事没完成？
3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）
4. 如果有跟进人，谁负责跟进哪个？
有些问题需要后面的故事板（看板）解决，有些则需要一个叫做“跟进表”的东西，之后我们说完故事板再回来详细说明。
敏捷开发日常跟进系列之三：故事板，看板
故事板和看板其实不是一个东西，前者是最初的敏捷开发里边的东西，受到了后者的启发产生的；而后者是制造业的东西，具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西，可以认为大致相同。
故事板
简单说，故事板是展示迭代中的用户故事和任务的方法，在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板：
一般故事板分为三列：
To Do还没做的, Doing正在做的, Done做完的（有各种各样的中英文写法，大同小异）
有些团队的分工比较多，会出现一些中间状态，比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。
故事板的用法
要解决的问题
故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：
1. 有哪些故事正在做，还没有做，已经开工了但没完成……？故事板的三列正好解决问题。
2. 最后剩下了哪些故事没完成？最左边剩下的就是。
3. 有没有人不是一个一个完成故事，而是同时开工了很多故事？（这个是最后很多故事都开工了但都差一点完成不了的主要原因）这个复杂一些，下面讲。
同时开工很多故事，很容易造成思绪散乱、最后全部完不成的情况，确切说瀑布模型就是同时开工所有故事的典范。
为了防止这一点，如果是手工做的故事板，，那么注意中间一个“正在做的”列一点要窄一些，这样当里边的故事挤不下的时候，就是一个危险的很多故事都在开工的信号。
还有一种做法，是每个人只准放一个故事在中间，做完一个，才能再做一个。这个严格坚持有难度，因为经常遇到被卡住的情况，但是作为一种思路和精神应该尽量坚持。
4. 如果有跟进人，谁负责跟进哪个？可以在卡片上写上当前负责人、跟进人的名字。
通常的做法有很多种，比如每个人用自己颜色的即时贴，可以比较容易地看出每个人有多少个故事，分别处于什么状态。不过，这样就需要在“尚未开始的”里边提前分配人员了，不太利于后期的互动和互相关注；当然还可以在开始的时候重新用有颜色的即时贴重新抄一个，看大家的习惯了。
介质
尽管有很多故事板/看板工具，使用纸质方法仍然是一个很好的选择，原因就是作为“迭代中的任务”这种东西，其生存期很短，基本上2个月后价值为0，人们也就用纸片来对付了。
不过如果想在未来做几件事情，那么及早采用电子故事板/看板还是有必要的，这些事情包括：
1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等
2. 大型团队，分布式团队
3. 希望留下历史数据作为以后估算的参考值和参考故事
下面这个是免费工具火星人中的故事板，做了两个案例来说明一下情况。
上面这个图是不好的情况，开发中的故事一大堆，没几个完成的，很容易造成最后所有故事都差一点。
下面这个要好的多，每个人只开工了1个（每种底色是一个人，案例中只有cheny和yock 两个人），剩下的要末完全做完了，要么一点没做，即使到期末不能全部完成，也不会把太多时间卡在半截的故事上。
2012-03-07补充：
昨天下午仔细调整了美术效果，现在的故事板外观如下：
更多
敏捷开发日常跟进系列之四：跟进表
这是敏捷开发日常跟进系列的第四篇。（栏目目录）
跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中，他们为了清晰地显示整个团队的运作方式，使用了这种方法。
跟进表
以上面的网络游戏团队为例，说明一下跟进表上的信息：
1. 哪些故事完成了
在故事板中也能表达，但缺少结构性。故事板中的故事都是平等的，较难显示大小、父子包含关系等。
2. 谁在跟进
案例中这个人一般是策划人员，故事的创建者和验收者。
3. 谁在开发
案例中这个一般是若干个开发人员、脚本、美术的群体，也可能只有其中一个工种。
4. 某个任务大概可能在何时开始、结束。
在故事板、燃尽图上均无法表达。
5. 哪些故事被搁置了
可能遇到了困难，也可能有其他原因，甚至可能做了一半干别的被忙忘了。
……
实例
这是一个在“火星人”研发中已经完成的迭代的跟进表案例。
实例一
我们先看看这个迭代的燃尽图（看不清楚请右键-图片另存为后观看）：
对于跟进图的5个作用，上面这个已经扩展了的燃尽图只能完成第一个，就是“哪些故事完成了”，而一般的燃尽图连这个作用也没有。
为了完成另外四个目标，就需要下面的跟进表。
先看左边的蓝框，里边是所有迭代中的故事（Sprint Backlog），为什么要显示成这个树状结构呢？因为如果是小团队，只有10～20个故事，那么人们即使从只有3个字的故事名称比如“新界面”上，大家也能记住和理解说的是什么意思。但是如果故事多了，就比较困难，会导致故事的名字不得不很长，比如“计划会-讲解故事-的新界面”，而这样表达看似还行，但由于没有清晰的父子包含关系，多了也乱。所以蓝框中以父子关系的方式表达，对于大型产品的研发更清晰一些。
蓝框右边两列是负责人（对应跟进人，案例中的策划人员）和当前负责人（开发人员），由于我们的团队小，不存在两个部门，所以没有设置跟进人，所以也就没有“负责人”。
三个黄框（一横两竖）所框住的表格的底色有的是绿色，有的是粉红色，绿色是加班，粉红色则是假期或休假。左边竖框标明15日大家集体加班，原因是右边竖框中大家19日集体放假外出春游；横向的黄框则标明yock在这个月有大量休假，他只能在特定日期完成工作。为什么要管理这些呢？有时候看似燃尽图正好指向0点，但那个地方可能正好是春节、五一、元旦什么的，有了对假期的整体把握，对重要的上线活动就降低了风险。
红框中的故事看上去就有点异常，因为尽管整个迭代结束了，它的剩余时间居然还是“1人天”，所以这个故事没有完成，它停在了17日。
实例二
下面的图，是调整了一些数据，并将系统时间调整到2.26，模拟一个正在进行中的迭代。
从最右边可以看到有4个故事没有完成，其中两个是尚未开始（最上面和最下面两个浅色的），另外两个则是遇到了障碍，卡在了17日和24日，之后没有进展。
作为项目经理和技术经理，在跟进表中看到遇到障碍的故事，就要及时询问和协调；作为程序员，也应该在每日立会上报告被卡住的故事。
沉默的程序员，又聋又瞎的项目经理（越大型团队的项目经理就越严重），是造成大型项目纠缠不清最终失败的重要原因。
敏捷开发日常跟进系列之五：用户故事与MVC
用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。
但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。
本人在C++的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（现在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是没有见识过，下文中所描述的MVC，若没有特殊说明，均指https://www.doczj.com/doc/0411278936.html, MVC；但相信对Java中的MVC也有借鉴意义。
利用MVC实现用户故事的技法
如果您已经认可之六中产生用户故事的方法，那么也就得到了这样的一个用户故事树，右边则是为其量身定做的Controller-Action（来自实际项目）：
=================================== === 下面是对应的UsersController
--Users/Index
----
--/Users/Details
--/Users/User2Authorities --/Users/Users2Roles
--/Users/Freeze
--/Users/Edit
--/Users/Delete
--/Users/BatchCreate
注意看每个Controller实现了一个史诗故事（要管理的数据），每个Action则实现了一个（偶然多个）用户故事（用户的业务操作），有几个值得注意的地方：
1. 一个Controller几乎正好可以实现一个史诗故事
2. 一个Action因为正好是一个动词，所以几乎正好和一个用户故事对应。
有两个地方违反了，如“角色首页（新建+查看）”和“权限首页（新建+查看）”，因为为了方便我们在两个Index里边放了个新建用的TextBox，方便直接创建（因为角色和权限都只有一个名字而已，所以觉得犯不上做个独立页面了）。
为了能记住这一点，我们在故事的缩写名字上加了（XX+XX）的标记，为了日后能自动计数故事。
3. 用户没有“创建”故事，也没有Users/Create，因为用户只有两种正常的创建方法：Register 和BatchCreate，我们选择了后者。因此既没有“创建用户”这个故事，也没有“/Users/Create”这个Action。
4. 几个绿色箭头是“增强”类型的故事（详见之五），它们正好也不对应Action。
上面提到的是我们实际的一种用法，未必是普适的，但在我们项目中非常适合，甚至应该称为“舒服极了”。
这种史诗-故事与Controller-Action之间偶然的巧合，实际上背后有其必然性。
利用MVC实现用户故事的心法
MVC以往研究的重点，是何为M，何为V，何为C，以及三者之间的关系。
我们在用了一段时间后，发现其中的每一个，都还有更深层次的理念在里边，这里谈的就是Controller及其Action。
在MVC三者呆在一起的时候，问：何为Controller？估计还是挺容易回答的。
但如果不提MV，直接问：何为一个Controller？何为一个Action？却挺难回答的。
如果去一个非MVC的网站或软件，最令人烦恼的，是网站的每个页面未必有自己独立的链接，比如逛了半天，顶上的链接一直是http://xxx.../login=xxxx，想为某个页面加个收藏夹都不行。MVC在很大程度上解决了这个问题：要操作的数据是Controller，要做的操作是Action，而参数则是具体操作谁，比如/Users/Details?user=cheny或CSDN博客上常见的：https://www.doczj.com/doc/0411278936.html,/cheny_com/article/details/6616794样式。
所以如果已经按照之六中提到的数据-操作方法来组织史诗-故事结构了，而且又在使用MVC,则非常推荐编程时将其继续映射到Controller-Action中。
可能细心的读者已经注意到本文图中有些故事后面有个链接符号，那个正是我们在已经实现了的即金色的故事的后面，加上了其超链接（全部是/Controller/Action，一一对应，非常舒服）。这相当于一个Action写好了，一个故事（偶然情况是多个）就正好也完了；而测试人员就可以点击那个链接去到Action测试。他测试完了Action，就能说故事被测试完了（而不只是Action被测试完了）。
以这种方式来对应用户故事和开发内容，产品经理和开发人员很容易沟通，因此非常推荐使用。
用户故事vs. FPA功能点分析法vs. MVC
?功能点分析法（FPA）、敏捷开发用户故事、https://www.doczj.com/doc/0411278936.html, MVC在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。因此若能将它们联合应用，就可能用一种组织方式贯穿性地管理估算、需求管理、架构设计三者。
完整地表述三者的关系，大致如下：
敏捷开发日常跟进系列之六：验收标准
要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。
面向客户价值设定验收标准
简单说，就是客户看到说“完成了”，才算完成了。
从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功能联合运行，前后数据完整一致才可以做到。在“敏捷产品管理”系列中，还会更加深入地探讨这个话题。
下面的例子，很好地表明了客户眼中的完成标准，它是EA（电子艺界，世界最大的游戏发行商和开发商之一）用于判断游戏中不同故事完成标准的。
—S =Sufficient for feedback. “可获得反馈的”（第一次能看得见的）
—Generally the firsttime something can be seen in software, however incomplete.
—W=Working. “能运行的”（能用，但是艺术性欠佳的）
—The functionality isbroadly in place but art work (e.g. graphical quality, UI) may be very lowfidelity or placeholder.
—T=Testable. “可提交玩家测试的”（可以交给玩家而不会破绽百出的）
—(by kids in ourcase). The software is sufficiently done to put it in front of people that havenot seen it before and for them to be able to use it with minimal intervention.
—A=Alpha. “可提交Alpha测试的” （改改BUG就可以上线的）—Potentiallyshippable, likely needing some polish and bug fixing.
—G=Great. “完美的”（可以上线而且估计反响强烈的）
—Shippable and likelyto receive a great review score.
为什么要搞这么复杂呢？因为游戏中有些功能，在开发出来之前策划人员也说不明白怎样才是好，但又急于开发出来看看，因此会采用最低标准S，就是能用就行，不测试，不写文档，不做性能优化……而另外一些功能，则可能比较正式一些，比如需要给某些玩家看到的，就会选择T或A级别；而正式功能，则会选择G。
不同的公司，有不同的客户群，为了不同的目的，需要制定自己相应的完成标准。
客户价值与工程实践的映射
上面是一个完全面向客户价值编写的完成标准，看起来很好，但是实践起来开发人员很难把握。
其实，每个面向客户价值的标准，背后都有相应的工程标准。在熟悉之后，开发人员一望便知。比如下面是上述标准中S和W标准的工程实践描述：
—W能运行的=
—编码完成√
—单元测试√
—手工功能测试√
—压力测试
—可回归自动测试
使用手册
—S可获得反馈的=
—编码完成√
—单元测试
—手工功能测试
—压力测试
—可回归自动测试
—使用手册
使用方法
上述面向价值的描述及其工程实践映射，不是在迭代计划会上现场想的，而是早就在项目之初就在项目甚至组织层面设置好了的。
在迭代计划会上，PO每讲完一个故事，都会在团队估算前指出故事完成的标准，这样团队就知道是不是要花费额外的测试、优化等工作量了。
不过，即使事先约好完成标准，若PO与开发组分开一个月，仍然可能得到一个”惊喜“。这就需要下篇提到的用户故事的开发与跟进。
敏捷开发日常跟进系列之六：开发与跟进
产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。
需求精化
这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一半的半成品后做一些细化或更正）。
一般认为产品负责人在开发的中间来打扰开发组工作是不令人欢迎的行为，那这两者之间到底区别何在呢？
在以后将会编写的一个《敏捷开发产品管理》系列中将会提到，产品负责人要做到“迭代期内无变更”，必须要做好长周期的研发管理，就是为每个版本每个迭代提前设定好目标。因此落实到具体迭代的时候，这个目标不是那么容易发生变化的，但“如何更好地达到这个目标”，则可能经常在变化。
需求精化的过程，就是产品负责人帮助团队更好地达到目标的过程。
“需求精化到底包含哪些活动？”确切说，只要把产品负责人和团队放在一起，什么事情都可能发生。
可能会对模糊的需求进行细化；可能会根据半成品做一些调整；可能给开发人员讲解一下用户背景……总之试一试，就知道了。
NEC的迭代开发中甚至有一个固定的时间（忘了是一个月中的第10天还是第20天），产品负责人会帮助全组对下一个迭代的故事进行一次提前通告，以帮助团队预测到以后发生的故事，从而略微地为未来做一些准备。这种准备既有提前了解业务的方面，也有潜在的在架构上为扩展做一些有限的准备。
跟进人，渐进评审
若开发组的人数众多，而产品负责人只有一个，他的工作会相当繁忙，顾此失彼。
跟进人制度是在产品负责人团队基础上建立起来的。所谓产品负责人团队，就是多个对产品了解的人组成一个团队，集体行使产品负责人的职责，典型的如软件或嵌入式产品研发中的产品总监-产品经理-产品专员团队，游戏团队中的主策划-策划组长-策划团队。
而跟进人，就是针对某个用户故事，指定相应的产品负责人团队的某个组员，来跟踪故事的开发进展。
跟进人最大的好处，是可以在用户故事一完成的时间点就进行评审、改进，防止了到最后却发现故事实现的不好，一则返工浪费时间，二则影响了上线日期（只能下个迭代修改）。
跟进人制度和渐进式评审在网络游戏的敏捷开发中非常普遍，原因是网游的策划人员比较多
软件开发质量保证体系集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
软件开发质量保证体系 1. 使用范围 2. 引用标准 3. 定义 4. 质量体系框架 管理职责? 质量体系 评审 纠正措施 5. 质量体系生存周期 合同评审 需方需求规格说明
开发计划 质量计划 设计和实现 测试和确认 验收 复制、交付和安装 维护 软件开发质量保证体系 公司内部标准 本标准参照ISO9000-3 《质量管理和质量保证标准第三部分：在软件开发、供应和维护中的使用指南》。
1、使用范围 本标准作为本公司在软件项目开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。 2、引用标准 本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。 使用本文档时，请尽量参照最新版本。 3、定义 产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。 开发：创作软件产品的所有活动。 供方：指本公司。 需方：指具体项目的需求方，即客户。
质量体系：质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。 4、质量体系框架 管理职责 供方(及具体的项目开发组)负责以下职责 组织机构 本公司内部专门设立部门质量保证部门，由部门负责人及专门经过培训的人员组成。具体项目开发组，设立质量保证组，或委托公司质量保证部门协助开展工作。 质量保证部门负责以下工作： 建立并维护公司内部的质量保证体系。 对可能导致产品不合格的问题予以识别，采取措施予以避免。 发现并记录产品的质量问题。 提出、采取或推荐问题解决办法。 验证解决办法的实施效果。 对不合格产品的处理、交付过程进行控制，确保最终问题得以纠正。 质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。
软件开发质量保证体系
软件开发质量保证体系来自https://www.doczj.com/doc/0411278936.html, 1. 使用范围 2. 引用标准 3. 定义 4. 质量体系框架 4.1 管理职责 4.2 质量体系 4.3 评审 4.4 纠正措施 5. 质量体系生存周期 5.1 合同评审 5.2 需方需求规格说明 5.3 开发计划 5.4 质量计划 5.5 设计和实现 5.6 测试和确认 5.7 验收 5.8 复制、交付和安装 5.9 维护 4.1管理职责
4.1.1 供方(及具体的项目开发组)负责以下职责 组织机构 本公司内部专门设立部门质量保证部门，由部门负责人及专门经过培训的人员组成。具体项目开发组，设立质量保证组，或委托公司质量保证部门协助开展工作。 质量保证部门负责以下工作： 建立并维护公司内部的质量保证体系。 对可能导致产品不合格的问题予以识别，采取措施予以避免。 发现并记录产品的质量问题。 提出、采取或推荐问题解决办法。 验证解决办法的实施效果。 对不合格产品的处理、交付过程进行控制，确保最终问题得以纠正。 质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。 制定质量方针和质量目标 确保项目组成员均理解质量方针并能坚持贯彻执行。 公司内部制定一般性的质量方针及对软件产品的质量目标，作为各项目组的参照，各项目组可根据具体客户期望及需求作出具体质量目标及质量承诺，具体质量目标及承诺，特别是超出公司目标的部分，提交给质量保证部门，以便提交给质量保证部门充分理解并协助实施。 《质量方针和质量目标》见附录 管理评审 质量保证部门负责人应每月对质量体系进行评审，主要是对内部质量审核结果的评定，以保证质量体系持续有效，保存评审记录。 4.1.2 需方（客户）应负的职责 在项目中，应向需方（客户）提出具体要求，明确其需要承担的职责，以便相互配合，共同保证项目的顺利实施。 需方应明确指定项目相关负责人，应具有足够的权力处理以下问题： 向供方提出需求 回答供方提出的某些相关问题 认可供方的提案 与供方签订协议并能确保遵守签订的协议 规定验收准则和规程 向供方提供必要的信息,提供有利的环境并解决项目中一些障碍。 4.1.3 共同评审 双方定期地交流，并联合评审软件是否满足已经商定的需求规格说明书。
[主题] 软件质量管理保证体系 文档作者：微软中国 撰写时间：[发布日期] 文档状态：[状态] [单位] 2
修订记录
目录 修订记录 (2) 目录 (3) 公司内部标准 (4) 1．使用范围 (4) 2．引用标准 (4) 3．定义 (4) 4. 质量管理体系 (4) 4.1软件质量管理责任分配 (4) 4.2工作产品和活动 (5) 4.3评审 (6) 4.4质量保证（QA） (8) 4.5 软件测试 (10) 4.6 配置管理 (11)
公司内部标准 本标准参照CMMI3《质量管理和质量保证标准》 1．使用范围 本标准作为本公司在软件项目开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。 以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。 2．引用标准 本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。 使用本文档时，请尽量参照最新版本。 3．定义 产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。 开发：软件产品的所有活动。 供方：指本公司。 需方：指具体项目的需求方，即客户。 质量体系：质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。 4. 质量管理体系 4.1软件质量管理责任分配
4.2工作产品和活动
4.3评审 评审是以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的流程。 对于任何工作产品的审计，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及陪审员若干。评审组的成员可以包括PPQA、项目组成员，但不能有作者的直接领导或者管理者。 评审小组先召开一个预备，作者会针对工作产品向大家做个总体的介绍，例如讲解一下本工作产品的目标是什么，以及其相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单。 评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会议之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。
Scrum 敏捷开发过程实战 产品级,大团队的敏捷实战方法 与传统灌输理念的培训不同,此实战培训中不只包含“按客户价值进行优先级排序”“利用自组织团队发挥主观能动性”等含糊的指导性思想,更在每个阶段均介绍一种或多种直接可以使用的方法来完成落地。 按照实际项目的开发顺序,培训分为三个环节,其主要内容如下: ● 需求结构化与需求描述(主要受众为产品负责人Product Owner 、团队骨干) ? 将产品愿景转换为可实现的业务需求; ? 将高层业务需求分解为具备层级结构的需求树; ? 编写用户故事,面向用户使用场景而非产品功能描述单条需求; ● 版本规划与迭代计划(主要受众为产品负责人、Scrum Master,团队骨干) ? 在宏观层面上,确认整个产品中所有子系统的优先级,并将其顺序计划到版本与迭代中; ? 在微观层面上,利用Scrum 计划会估算每个迭代中任务的工作量; ● 日常活动与团队建设(主要受众为Scrum Master,团队成员) ? 日常活动中,利用每日立会、故事板、瞧板跟进开发进度; 需求结构化 需求描述 版本规划 迭代计划 日常活动 团队建设
?团队建设中,利用自组织团队、松结对编程等方法建立师徒制度,在实际工作中培养队员; ?在大型、跨职能团队研发时的团队结构与工作方式 ●附:敏捷设计与工程实践(仅出现于3天培训中,主要受众为团队成员及技术管理者) ?如果从用户故事经过简单设计得到代码结构 ?如何利用用户故事来产生、管理测试用例 ?如何利用用户故事来管理变更、缺陷与客户反馈 课程将围绕每个小组实际工作中各自产品或项目的自身需求展开,通过对其进行结构化、用户故事化、用户建模、模拟计划会估算、设定验收标准等,从而演练Scrum各个环节所需的技能。知识及案例讲解约占70%,实际练习约占30%。 注:本大纲中以一个易于理解的电子商务系统的研发为例,实际应用时可应用于银行、电信、政府、电子商务、互联网社区娱乐、仪器仪表等各种主流行业。 ×××××××××××××××××××××××××第一天×××××××××××××××××××××××××××××× 0概述 本阶段培训通过简短介绍,让学员大致了解敏捷开发的历史及其尝试解决的问题。 ●敏捷开发尝试解决的问题 ●Scrum及其历史 ?产品负责人 Product Owner ?产品负责人团队 ?产品负责人的职责 现场演练:分组并推选Product Owner 1第一阶段:需求结构化与需求描述 本阶段培训旨在从头到尾打通需求,即从感性的产品愿景分解到可供开发的具体需求条目。
敏捷开发流程详解by yangdl 1敏捷开发流程 ?敏捷软件开发核心是迭代式开发，增量交付。 ?每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。 ?迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。 ?迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。 1.1敏捷流程详解图-敏捷流程图 1.2敏捷流程三种角色及其职责
1.3敏捷开发流程详解 1.3.1流程图详解步骤 1.制定产品需求列表 ?PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表； 2.召开计划会议 ?PO召集TM和SM（也可邀请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物， ?冲刺计划就是确定该冲刺阶的长度（建议冲刺长度1-4周）、目标和冲刺任务单及其工作量估算
（以理想人天manday=7.5h估算，单位为小时计算），会议时间建议不要超过6h时间； ?在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集 成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关人员； ?项目计划会议上可以确定每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决， 在私下进行沟通，不要在会议上讨论。站立会上只有TM人员有发言权，其他人员不要干预，SM 主要是维护秩序、规则及其引导作用。 3.需求分析、设计、编码和测试： ?计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试； ?这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等）。具体情况，需要 项目组根据实际情况决定，但客户要求交付的文档必须要输出； 4.冲刺任务单和燃尽图更新 每天SM需要根据每日站立会上TM反馈的情况，进行更新冲刺任务单和燃尽图或SM和TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。 5.迭代周期结束点 ?已到迭代周期结束点，只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。 ?这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需 求列表中挑选优先级高的进行开发。 6.冲刺评审会议 ?TM需要召开冲刺评审会议，邀请PO、客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时，参加人员除PO及其相关利益 人来参加外，TM全体成员，也可以邀请其他相关人员参加。 7.冲刺回顾会议 ?迭代输出的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭 代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括：
软件开发质量保障方案 一、质量管理内容 1.1.编制和评审质量计划 制定质量保证计划：依据项目计划及项目质量目标确定需要检查的主要过程和工作产品，识别项目过程中的干系人及其活动，估计检查时间和人员，并制定出本项目的质量保证计划。 质量保证计划的主要内容包括：例行审计和里程碑评审，需要监督的重要活动和工作产品，确定审计方式，根据项目计划中的评审计划确定质量保证人员需要参加的评审计划。明确质量审计报告的报送范围。 质量保证计划的评审：质量保证计划需要经过评审方能生效，以确保质量保证计划和项目计划的一致性。经过批准的质量保证计划需要纳入配置管理。当项目计划变更时，需要及时更改和复审质量保证计划。 1.2.“过程和工作产品”的质量检查 根据质量保证计划进行质量的审计工作，并发布质量审计报告。 审计的主要内容包括：是否按照过程要求执行了相应的活动，是否按照过程要求产生了相应的工作产品。本项目中对质量的控制主要体现在不同阶段的审计当中。 1.3.不符合项的跟踪处理 对审计中发现的不符合项，要求项目组及时处理，质量保证人员需要确认不符合项的状态，直到最终的不符合项状态为“完成”为止。 二、质量管理责任分配 开发项目上按照规范化软件的生产方式进行开发。每个项目除配备了项目开发所需角色外，还专门配备了质量保证小组、配置管理小组、测试小组来确保质量管理的实施，下面针对这三种角色进行说明：
2.1.质量保证小组职责 质量保证小组作为质量保证的实施小组，在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组的主要职责是：以独立审查方式，从第三方的角度监控软件开发任务的执行，分析项目内存在的质量问题，审查项目的质量活动，给出质量审计报告。就项目是否遵循已制定的计划、标准和规程，给开发人员和管理层提供反映产品和过程质量的信息和数据，使他们能了解整个项目生存周期中工作产品和过程的情况，提高项目透明度，从而支持其交付高质量的软件产品。 质量保证人员依据质量保证计划，通过质量审计报告向项目经理及有关人员提出已经识别出的不符合项，并跟踪不符合项的解决过程，通过审计周报或者审计月报向项目经理提供过程和产品质量数据，并与项目组协商不符合项的解决办法。 质量保证小组的检测范围主要包括：项目的进度是否按照项目计划执行，用户需求是否得到了用户的签字确认，软件需求是否正确的反映了用户的需求，是否将每一项用户需求都映射到软件需求；系统设计是否完全反映了软件需求；实现的软件是否正确的体现了系统设计；测试人员是否进行了较为彻底的和全面的测试；客户验收和交接清单是否完备；对于系统运行中出现的问题，维护人员是否记录了详细的维护记录；配置管理员是否按照配置管理计划建立了基线，是否严格控制变更过程，是否对配置库进行了维护。 2.2.配置管理小组职责 配置管理活动的目的是通过执行版本控制、变更控制、基线管理等规程，借助配置管理工具的使用，来保证整个生命周期过程产生的所有配置项的完整性、一致性和可追溯性。配置管理是对工作成果（阶段工作成果和产品成果、进展状态成果）的一种有效保护形式，是反映项目及其工作产品的过去、现在、动态的资料和数据集中管理体现。 配置管理小组的主要职责包括：根据项目计划制定配置管理计划，建立配置库，为项目组人员分配配置库权限，创建需求、设计、开发、测试、交付阶段的基线。当纳入基线库的工作产品发生变更时，严格按照配置项变更控制过程执行变更，变更后建立新的基线。 2.3.测试小组职责 作为质量控制的主要手段，如同软件开发一样，测试在执行之前，测试小组制定软件测试计划、测试用例的编写和执行工作。 测试可以分为如下几种类型：代码走查、单元测试、集成测试、系统测试。为了保证程序的质量，开发人员需要对同伴的代码进行代码走查，同时对自己编写的程序进行单元测试，确保程序编译、运行正确。
敏捷开发的相关简介 敏捷定义 Scrum是一个轻量级的软件开发方法 Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。 在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint 中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。 敏捷的原则 个体与交互胜过过程与工具 可以工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 这四句价值观用语句表达就是： 自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件。 胜过 与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求。 《敏捷宣言》12条原则 1.最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。 2.欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户取得竞争优势。 3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。 4.在整个项目中业务人员和开发人员必须每天在一起工作。 5.以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作。 6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。 7.可用的软件是进展的主要度量指标。 8.敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调。 9.简化——使必要的工作最小化的艺术——是关键。
关于软件质量管理体系建设的 方案 参考资料: 《cmmi3级软件过程改进方法与规》 《ISO9001:2000标准》 修改记录: 作者简介： 软件企业质量经理、高级项目经理，联系方式__qq:317974257 方案说明： 参考了《cmmi3级软件过程改进方法与规》、《ISO9001:2000标准》。同时参考了业界同行写的相关方案或文章，吸收了他们的优秀见解。
1.引言 (3) 1.1软件质量概述 (3) 1.2公司软件质量现状分析 (3) 1.3软件质量管理的特点 (4) 1.4软件质量责任分配 (6) 2.软件质量管理体系建设总体方案 (6) 2.1进一步推动软件质量管理体系建设的原则 (6) 2.2软件质量管理体系完善需要解决的主要问题 (8) 2.3配置管理—实施软件质量管理的重要步骤 (8) 2.4进一步完善我们的测试管理体系 (10) 2.4.1.软件测试的组织与管理规划 (10) 2.4.2.测试管理体系过程控制 (12) 2.4.2.1测试流程模型 (13) 2.4.2.2测试流程控制 (13) 2.4.2.3测试小结 (15) 2.5软件质量保证（SQA）的实施 (16) 2.5.1.SQA概述 (16) 2.5.1.SQA实施 (16) 2.5.2.SQA与SQC区别与协作 (17) 2.6全面软件质量管理 (18) 2.6.1.全面软件质量管理 (18) 2.6.2.全面软件质量管理的方法---制定质量管理计划 (19) 2.6.3.全面软件质量管理的方法---技术评审 (19) 3.结束语 (19)
1.引言 1.1软件质量概述 随着信息技术的飞速发展，使软件产品应用到社会的各个领域，也造就了软件行业激烈竞争的生存环境，随着软件规模及复杂性急剧加大，软件质量已经成为人们共同关注的焦点。技术是软件企业的生命，而质量则是它的灵魂,软件企业要在竞争中占有一席之地，软件质量保证是第一要素。由此，软件质量的重要性是不言而喻的。 软件质量是指与软件产品满足规定的和隐含的需求的能力有关的特征和特性的总和。通常来说，软件质量应该包含六方面的特性: 功能性、可靠性、易使用性、效率、可维护性、可移植性。 软件质量管理包括：软件质量计划编制、软件质量保证和软件质量控制三个过程域。质量计划就是为了实现质量目标的计划,它主要结合各个公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证（Quality Assurance ，QA）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。 1.2公司软件质量现状分析 公司的软件开发历经多个生产个环节，产生大量的中间产品，每个环节都有可能带来产品质量问题；同时由于软件产品是逻辑体，不具备实体的可见性，因而难以度量，质量也难以把控，因此如何有效地管理软件产品的质量一直是我们面临的挑战。
敏捷开发在项目开发和管理中的实践和应用 摘要敏捷开发已深入互联网产品的研发和团队管理过程，当前互联网+时代要求软件研发企业在面对市场需求是要能够做到快速响应，传统的瀑布开发模式已经不能满足互联网企业一系列的需求。敏捷开发提倡拥抱变化、高效沟通、持续交付、紧密协作，强调团队的自组织，本文根据实际应用情景，谈一谈在敏捷开发过程中，通过简化工作流，提升团队协作和沟通，来提高项目管理的效率，降低成本、实现产品的快速交付。 关键词敏捷开发；信息系统；项目管理；软件开发 敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方式，目前主要有Scrum、XP和看板模式。敏捷采用的是迭代式开发，主要驱动核心是人。目前许多敏捷开发在实际应用还处于摸索阶段，只注重“形”，为不注重“神”，通过多个敏捷项目的实践，在采用一种新的模式的时候，最好结合实际进行本地化的适配。 1 敏捷项目的需求确认与任务分解 敏捷项目是欢迎用户需求变化的，项目开始阶段不需要完整的需求，但也要能准确获取客户的需求，系统原型设计是使用最普遍的方法。给客户演示原型并不断修改原型直至客户确认，可以有效地与用户针对系统的功能与可用性进行验证，节省开发前研发资源的投入，确保构建系统的正确性，开发初期原型设计的开支远低于开发实际系统的开支。常用的原型设计工具：Axure RP、Microsoft Visio、网页制作工具。 在管理用户需求时，产品负责人（Product Owner，简称PO）要将需求整理成用户故事，用户故事通过product-backlog（产品backlog）进行记录。在每个迭代开始之初，由团队负责人（Scrum Master，简称SM）召开sprint计划会议，PO负责需求的讲解，开发团队通过需求的理解，一起进行用户故事的估算。在计划会议中需要确认需求优先级、分析和评估产品Backlog，确定迭代的目标，分解工作内容，形成迭代任务（Sprint backlog），然后为本次迭代任务做估算；团队成员从产品Backlog中挑选他们承诺完成的用户故事。 2 敏捷项目的系统分析与设计 敏捷开发可以根据项目的规模对设计工作进行取舍，一般在项目开始阶段先引入一个sprint0，进行系统的分析和设计工作，敏捷开发不提倡刚开始就进行完整的系统设计，主张先做出一个大粒度的框架性设计，然后在迭代开发中逐步深入细化，当然传统的一些设计方法也可以融入敏捷开发过程。 2.1 整体架构和逻辑架构设计
大型软件开发过程的质量管理体系 韩思音 弋陪余 国信朗讯科技网络技术有限公司是中国电信和朗讯科技合资的专业从事通信网络管理软件开发的高科技企业，公司位于上海浦东，注册资金２ ９８０万美元，员工达１５０人，本科以上学历超过９５％。公司在１９９９年成立后就开展了ＩＳＯ９００１贯标活动，并于２０００年８月通过了ＩＳＯ９００１认证。公司以贝尔试验室的大型软件开发管理流程为基础，建立了自己的ＩＳＯ９００１质量管理体系。三年来已经开发了“传输网络集中监控系统ＮｅｔＧｕａｒｄ”、“电信网络资源管理系统ＮｅｔＭａｓｔｅｒ”两个大型软件系统。通过ＩＳＯ９００１的贯标活动，加强了公司全体员工的质量意识，强化了软件开发过程的规范性，改进了软件开发过程，保证了软件开发的质量，对加强公司实力、提高市场形象起了很好的推动作用。 通过了ＩＳＯ９００１认证后，审核机构每年要进行一次复查，即监督审核。如果公司质量体系运行得不好，就可能被暂停证书；如发生重大事故，证书可能被撤消。除此以外，公司每年还进行一次内审，即公司内部对质量体系运行是否符合ＩＳＯ９００１标准进行的检查，各部门对内审发现的不符合项进行认真整改，由质量管理部验收。各部门对本部门的工作定期提出改进措施，由质量管理部对其进行验证，使质量体系不断改进。所以ＩＳＯ９００１的认证对企业的质量体系是有严格管理的，是有保证的。 １ 软件产品质量的特点 按照ＩＳＯ９１２６的定义，软件的质量通常可以从以下六个方面去衡量（定义）。 １）功用性（Ｆｕｎｃｔｉｏｎａｌｉｔｙ），即软件是否满足了客户功能要求。 ２）可靠性（Ｒｅｌｉａｂｉｌｉｔｙ），即软件是否能够一直在一个稳定的状态上满足可用性。 ３）可用性（Ｕｓａｂｉｌｉｔｙ），即衡量用户能够使用软件需要多大的努力。 ４）效率（Ｅｆｆｉｃｉｅｎｃｙ），即衡量软件正常运行需要耗费多少物理资源。 ５）可维护性（Ｍａｉｎｔａｉｎａｂｉｌｉｔｙ），即衡量对已经完成的软件进行调整需要多大的努力。 ６）可移植性（Ｐｏｒｔａｂｉｌｉｔｙ），即衡量软件是否能够方便地部署到不同的运行环境中。 可见，同其它产品相比，软件产品的质量有其明显的特殊性。
正式考试内容以课后习题为主，我已亲测考过！ 1 一、单选题。每道题只有一个正确答案。 1、To char函数的作用是？ A 数字转换为字符 B 将字符转换为日期 C 将数字转换为日期 D 将字符转换为数字正确答案A 二、多选题。每道题有两个或两个以上的正确答案。 1、常见的数据类型转换函数是？ A to_number B to_date C to_char D 以上都不对正确答案ABC 2 一、单选题。每道题只有一个正确答案。 1、nvl函数的作用是（）。 A 将空值转换为指定的值 B 将指定的值转换为空值 C 将数字转换为日期 D 将与指定字符相同的字符，输出为空值正确答案A 二、多选题。每道题有两个或两个以上的正确答案。 1、常见的转换函数是？ A nvl B nvl2 C nullif D coalesce正确答案ABCD 4 一、单选题。每道题只有一个正确答案。 1、avg分组函数的作用是（）。 A 求平均值 B 求最大值 C 求最小值 D 求累积和正确答案A
二、多选题。每道题有两个或两个以上的正确答案。 1、分组查询中应注意的问题是？ A 分组函数和单个列出现在查询中需要使用分组查询 B 出现在select关键词后的列名必须出现在group by 关键词之后 C 分组查询中可以使用order by语句 D 不能使用where限定组正确答案ABCD 5 一、单选题。每道题只有一个正确答案。 1、当分组函数处理的数据中含有空值时（）。 A 函数能够屏蔽空值的影响 B 函数不能处理空值 C 函数将报错 D 求累积和空值会被转变为0正确答案A 二、多选题。每道题有两个或两个以上的正确答案。 1、下列是分组函数的是？ A count B sum C min D max正确答案ABCD 6 一、单选题。每道题只有一个正确答案。 1、内连接的特点是（）。 A 表的输出是平衡的，即a表输出5行，b表输出5行 B 函数不能处理空值 C 函数将报错 D 求累积和空值会被转变为0正确答案A 2、自连接的特点是（）。 A 空值算入分母 B 空值算入分子 C 空值算入分母和分子 D 自连接是给一个表取不同的别名，当作两个表来使用正确答案D 7 一、单选题。每道题只有一个正确答案。 1、笛卡尔积查询的关键词是（）。 A cross join B select C from
软件开发质量保证体系 1.使用范围 2.引用标准? 3.定义? 4.质量体系框架? 管理职责? 质量体系 评审 纠正措施 5.质量体系生存周期 合同评审
需方需求规格说明 开发计划 质量计划 设计和实现 测试和确认 验收 复制、交付和安装 维护 软件开发质量保证体系
公司内部标准 本标准参照ISO9000-3《质量管理和质量保证标准第三部分：在软件开发、供应和维护中的使用指南》。 1、使用范围 本标准作为本公司在软件项目开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。 2、引用标准 本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。 使用本文档时，请尽量参照最新版本。 3、定义
产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。 开发：创作软件产品的所有活动。 供方：指本公司。 需方：指具体项目的需求方，即客户。 质量体系：质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。 4、质量体系框架 管理职责 供方(及具体的项目开发组)负责以下职责? 组织机构? 本公司内部专门设立部门质量保证部门，由部门负责人及专门经过培训的人员组成。具体项目开发组，设立质量保证
组，或委托公司质量保证部门协助开展工作。 质量保证部门负责以下工作： 建立并维护公司内部的质量保证体系。? 对可能导致产品不合格的问题予以识别，采取措施予以避免。? 发现并记录产品的质量问题。? 提出、采取或推荐问题解决办法。? 验证解决办法的实施效果。? 对不合格产品的处理、交付过程进行控制，确保最终问题得以纠正。? 质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。 制定质量方针和质量目标? 确保项目组成员均理解质量方针并能坚持贯彻执行。 公司内部制定一般性的质量方针及对软件产品的质量目标，作为各项目组的参照，各项目组可根据具体客户期望及需求作出具体质量目标及质量承诺，具体质量目标及承诺，特别是超出公司目标的部分，提交给质量保证部门，以便提交给质量保证部门充分理解并协助实施。 《质量方针和质量目标》见附录 管理评审?
软件工程质量管理体系说明 我公司已软件工程要求建立了质量管理体系，严格控制产品的设计和开发的策划和过程，确保新产品满足市场要求。 一：职责分工 研发总监 主管公司技术、产品发展方向的调查研究,确定新产品的开发项目和新技术的研究方向；主管新产品的确定、设计、开发、评审、验证、确认等过程；主管新产品市场推广的技术支持和新产品的试运行。 研发部 组织实施新产品开发之前的可行性调研； 参与对立项报告的评审； 实施新产品的形态设计，编制新产品研发计划； 负责根据公司技术发展战略开展技术研究和新产品开发及老产品的改造、升级工作； 负责针对每个开发的软件产品进行全方位的测试，保障产品质量； 参与对产品开发过程的阶段性评审和开发结束时的验收。 负责软件技术的积累和成长，产品的软件开发、测试，产品软件的技术支持等，对软件的质量和稳定性负责，部门成员参加具体的产品的软件开发过程。 二、开发要求 1、确立设计开发项目根据市场调查、技术发展或市场需要提出新产品立项或重大改进需求的由指定专人进行可行性调研，编写《立项报告》，申请立项；根据立项申请，由研发总监组织相关人员（必要时聘请专家）进行评审并对结果进行记录。 2、设计开发的策划由研发部成立专门的项目小组对已立项的新产品编制《设计开发需求》，然后开始系统设计，以此作为项目组成员进行设计开发活动的依据。应阐明设计项目的输入和输出要求、设计的进度要求、人工预计、任务描述、设计验收的时机等活动的安排，并规定实施这些活动的职责； 研发部在系统设计完成时形成设计文档，由项目小组进行内部评审，形成记录。然后开始进行程序代码开发；项目负责人的选定要求其具有相当的能力和经验，项目组成员的选定也要求遵循资源优化的原则，有利于提高效率，避开矛盾，使资源得到合理的配置；项
从敏捷开发到敏捷运维：DevOps将带来革命？ 你听说过DevOps一词，或者听说过敏捷运维这个运动么？人们越来越意识到传统意义上的开发行为 和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。传统的工作流程中，开发 和运维之间存在很多的沟通错位而造成部署上的问题，由此，DevOps理念应运而生。 如果你对IT管理感兴趣，尤其是对Web运维感兴趣，那么最近一定会注意到“DevOps”这一热词的出现。现在 #DevOps标签频繁出现在微博客Twitter上，同时DevOps相关的技术交流聚会也在慢慢增多。 在许多方面，DevOps是一个集合性概念，指的是能够理顺开发和运维之间相互配合关系的任何事物（51CTO编辑注： 在英文中，Developer指开发者，Operations指运维，所以DevOps一词本身含有开发+运维的意思）。但是DevOps背 后的理念要比上述说法更深远。 什么是DevOps？ 人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。 正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。 开发与运维之间的“混乱之墙” 以开发为中心的人通常认为，变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。 而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。我们已经多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变（根据51CTO之前进行的调查，很多时候，仅仅是给系统应用补丁就会造成生产服务器无法正常重启）。 开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。的确，孤立的来看他们都是正确的。 更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同管理者的和竞争关系，而且通常工作在不同的地点。
1.1质量保障措施 质量保障措施包括项目质量管理保障措施和软件开发质量保障措施两方面。 1.1.1项目质量管理保障措施 1、资深的质量经理与质保组 针对本项目，将派遣资深的质量经理参与质量保证组（简称SQA组）。SQA 组负责确保项目遵守质量保证体系的标准要求，确保遵循项目计划书中描述的要求，确保交付的软件及其文档以及非交付的软件在需求、设计及管理等诸多方面的质量。 2、全程参与的质量经理 质量经理，即质量保证组组长，监控项目成员的软件活动，并对软件产品与可适用的标准、过程和软件开发计划的符合性进行评价，为双方项目领导小组监控项目的软件生产提供适当的可视性。 3、合理的质量控制流程 质量经理负责对项目进行监控与分析，将结果报告给由双方高层人员组成的项目领导小组。项目经理批准发布给用户的所有文档和软件，必须得到质量经理的复核和批准。 质量管理规范 质量经理的工作依据为行业标准、客户方约定的管理规范和公司的管理规范，工作方式为编制质量计划、过程和产品检查、评审和审计、问题上报等。 服从工程监理 鉴于本项目的专业性和复杂性，如本项目中标，XXX将在系统建设、安装调试和验收等各环节严格服从专业监理公司的全过程监控，以保证整个项目的质量。 加强协调管理 由于本试点工程参加建设单位较多，需要统一协调与配合。如本项目中标，xxxx将积极配合、充分协调项目参与各方的关系，提高工作效率，团结一致共同建设本项目。 严格合同和计划管理 本项目内容复杂，如本项目中标，为保证工程建设的质量和建成后运行的质
量，在施工各环节将严格加强合同管理和计划管理，严格按合同及工作计划进行施工，确保工作质量。 重视培训 由于本项目内容复杂，专业程度较高，如本项目中标，xxxxx将把培训工作贯穿到整个建设过程中。本项目的培训不能按照传统的培训方式在项目完成后进行，在工程设计、施工阶段采用边设计施工边培训的方式，以便用户更快使用本系统，同时保证工程少出偏差，保证工程质量。 1.1.2软件质量保障措施 软件质量保障措施包括对项目资源的保障，对质量管理过程的保障和对产品质量的技术保障。 （一）对软件产品的测试 软件测试是对软件产品质量保障最重要的措施之一。 测试是评价检查质量目标实现的重要手段，过程如下： 软件质量评价过程与测试活动的关系如下图所示：
敏捷开发与敏捷测试 来源: cnblogs 敏捷开发：1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人” 的(people-oriented) 而非“面向过程”的(process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。 我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。 敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有多。改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。” 敏捷开发提出了以下遵循的原则： ·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 ·即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 ·经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 ·在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 ·围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 ·在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 ·工作的软件是首要的进度度量标准。 ·敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 ·不断地关注优秀的技能和好的设计会增强敏捷能力。 ·简单是最根本的。
2019年信息系统项目管理师复习笔记：十大知识领域1、整体管理 （1）制定项目章程 （2）制定项目管理计划 （3）指导与管理项目执行 （4）监控项目工作 （5）实施整体变更控制 （6）结束项目或阶段 2、范围管理 （1）规划范围管理 （2）收集需求 （3）定义范围 （4）创建WBS （5）确认范围 （6）控制范围 3、进度管理 （1）规划进度管理 （2）定义活动 （3）排列活动顺序 （4）估算活动资源 （5）估算活动持续时间 （6）制定进度计划
（7）控制进度 4、成本管理 （1）规划成本 （2）估算成本 管理储备+成本基准＝项目预算（3）制定预算 （4）控制成本 5、质量管理 （1）规划质量管理（2）实施质量保证（3）质量控制 6、人力资源管理（1）规划人力资源管理（2）组建项目团队（3）建设项目团队（4）管理项目团队 7、沟通管理 （1）规划沟通管理（2）管理沟通 （3）控制沟通 8、干系人管理 （1）识别干系人（2）规划干系人管理
（3）管理干系人 （4）控制干系人参与 9、风险管理 （1）风险管理规划 （2）风险识别 （3）定性风险分析 （4）定量风险分析 （5）风险应对计划 （6）风险监控 10、采购管理 （1）编制采购计划 （2）实施采购 （3）控制采购 （4）结束采购 2019年信息系统项目管理师复习笔记与习题：信息化和信息系统 1、信息的质量属性 （1）精确性 （2）完整性 （3）可靠性 （4）及时性 （5）经济性
（6）可验证性 （7）安全性 2、信息化从小到大分五个层次： （1）产品信息化、 （2）企业信息化 （3）产业信息化 （4）国民经济信息化 （5）社会生活信息化 3、两网：政务内网和政务外网 一站：政府门户网站 四库：人口、法人单位、空间地理和自然资源、宏观经济 十二金：金宏（第一类） 金税、金关、金财、金融、金卡、金审（第二类） 金盾、金保、金农、金水、金质（第三类） 4、信息化体系六要素（上“鹰”下“鸡”左“人”右“龟”）：（1）信息资源 （2）信息网络 （3）信息技术应用 （4）信息技术和产业 （5）信息化人才 （6）信息化政策法规和标准规范
敏捷开发实践拥抱变化的产品开发流程管理 随着Agile敏捷开发的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法，一直实践到现在，并取得不错的成果，包括：产品功能更加符合市场和业务人员的需求，开发效率获得提高。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和作者的敏捷开发体会。 敏捷开发体会 实施敏捷开发近两年来，我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品，在全世界都有客户，有10年历史，和一百多个基于不同版本的客户，我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品和自主的团队环境中进行敏捷开发体会尤其深刻。 1) 注重概念和架构设计，而轻详细设计 敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计，则是具体的设计和做法、API接口等。 一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每个模块的投入和收益的比例等，这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被客户使用，以后就很难在产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性，以及客户的升级迁移。所以，在开始正式开发之前，通过概念设计和架构设计，梳理思路是非常必要的。 2) SWOT分析 以前在做项目时，大多是从技术角度来考虑哪一些功能模块需要做，哪一些功能模块先做，而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源，却并不一定是客户最想要的。 在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析，就能选出付出最小工作量，但能获得最大价值的模块。 SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价比可以进行排序，选出最能符合市场的模块。