青蛙梦游志

与某人的矛盾渐深。如果所做的一切没有回报，不被所知，当然我会另寻它途。我不能让自己的成绩全部成就别人。也不能看着自己因为和善而承担别人的工作。总之，要另辟途径，目的

1、让外部看到自己

2、让某人引起更多内部的不满，让内部的不满反映到老板

不，这条不好。可能老板反而喜欢。要让他拒绝或者出错。

不给他答案？不，他比你更能调用资源。

哦，想一想，再想一想……

3、发掘自己的人脉

新的高度，新的问题，没有止境，真让人厌烦！

30，是我的坎。

生活上，偶结婚了。与老公交往近4年，结婚，真的只是一个仪式。这个坎，算是平平淡淡的过去了。

有朋友采访，结了婚有什么不同呀？~`想来想去，似乎没什么不同。球照打，网照上，唯一不同的是对父母有个交待了。说起来，他的球打得真是太多了，偶可是这么鲜活乱跳的免子呀~```不过我真觉得无所谓，我有我的爱好活动，两个人老在一起，可能倒反而全无新鲜感，久而久之，就是那什么手和什么手了。

有时候想想他那么爱打球，可能也和环境有关。我是成天和这么多的同事、客户打交道，同时处理这么多项目这么多问题，一天下来口干眼花头也晕，哪还有劲再和别人说话。而他哪，成天一个人待着，最多有客户或朋友过去聊聊行情，也就一个两个人，很容量产生压抑的情绪。到了俱乐部，好多人啊。。。聊天的打球的要多热闹有多热闹，立马这心情就不一样，再不好的情绪也不知被抛哪去了。而且还被这么多人从能力的角度上认同、赞美，温馨、欢快的同时被若干DDMM用景仰的眼神看着、拉拢着。。。估计轻了一半都有:p

所以，满好满好，健康（手腕脚踝倒是都有点伤了`）、安全（N多双眼睛帮我看着他呀~）、省钱（负责人打球不花钱，呵呵呵~），坚持吧，至少别让我喜欢的身材走了样。不过最近好象肚子已经起来了，以后要让他少喝点啤酒！

偶的球技是长不到哪去了，看来他也死心了，陪我练球的时候也不象以前那么老骂我偷懒了（骂的太多了灰心了也有可能~）。唉，加班加出差，老也打不上球，偶就是想练球也不行呀。看着别人都长球，其实偶也是心里满酸的。。。连公司同事都只夸我：你的姿势好标准啊。。。唉~不提了。

从工作来说，也是一个坎。在目前公司工作5年了吧，从基层技术人员做到项目经理。有点小得意的心理呢，是公司还是满重视偶滴。但是。。。自知的是，作为项目经理，真的狠不够。

公司的市场多数是几位老总在做，市场人员只是一小部分。而很多项目都不是那么规范的商业行为。所以项目经理，成了夹缝中的小草。

也许就是中国特色吧，和政府的合作总是含糊的。具体的事项并不在合同中声明，当然就是写明了也没什么用，反正客户的需求永远没有尽头。最郁闷的事情，莫过于一边整理着新项目的需求，一边被N多老客户的新需求、新问题、BUG报告。。。所打断。有时候只好下了班再写文档，效率反而快好多。系统先天不足也好，运营模式有问题也好，做为技术和服务的双重提供商，经常郁闷的看着自己在一个怪圈里绕来绕去走着无数重复的路。断点，需要一个可以找出问题解决问题的点。

资源不足是另一面总让我撞上的墙。这两年公司的开发人员流动变得很快，交接和培训完全跟不上。交接不清，无人维护，时间长了，很多程序就这样流失掉了，可惜啊，都是心血来的。这个不提了，突发任务的处理是个头疼的事。就这么多人，活都排得满满当当的。可是新任务总有要加塞的时候，于是协调这个协调那个，威胁利诱套近乎耍嘴皮子，18般武器全用上，也仍然是有30%左右需要部门经理来协调。于是就开会。我说没办法呀一定要做呀，开发的头说没人呀没法做呀~`真的是碰头会啊，大家一起来头碰头。即使是最终能分派下去的任务，也终会招至其它部门的抱怨，就你的项目组事多。于是我每次出差都大包小包的往回带吃的，搞得偶多馋一样，偶大好的形象啊。。。

叹气吧，其实我还算好的了，毕竟有开发的经验，在公司资历又比较久，还有。。。美女总会有点特权，与开发人员的沟通总算是还比较顺畅，有些BUG自己就处理掉了。其它的项目经理就更麻烦了，经常有些小事也得折腾上好几圈才能解决掉。不过我现在也不行了，事太多，不找人分担实在是吃不消了。

这也是年初提出辞职的原因，可是。。。作为最大项目组的项目经理，公司不是那么轻易放弃的。一方面许诺增加更多的人员、按我的提议调整各项目的优先级，甚至连那时候还属于高度机秘的上市及期权分配计划都搬出来给我看。看看，到明年这个时候就是几十万$啊。。。这个时候走很可惜的。。。

我终于没走，一方面上市是相当有吸引力，一方面真的对公司有依恋哦，真的是个滥好人呢~`

//突然因新项目被派北京出差一周，脸干干的脱着皮回来的。走前的一天，大老板请吃饭，说“你怎么不用点喷雾呢？我那有”。我说我明天都走了，留着我下次用吧。心里下决心，从来不用化妆品，不是不想，是过敏，反正我天生丽质，但是用点喷雾总不会过敏吧，回去就买！！接着写。

到这家公司其实挺有意思的，不是因为我会编程，而是因为我OFFICE用的好。当时公司还很小，虽然北京、上海、南京，但是几处人都很少，南京最多也不过10几个人。面试的时候，先由一个主管出题，考了些OFFICE的操作。由于做企划（是这个名份吧）的时候，做过大量的报表、报告、演示，又跟广告公司的设计人员混过几天，那些题实在挺简单。于是，面试的对面又是老总了。不过是个男的。其实走进公司后，一看这么点人，又听介绍是这么个工作，并不是特别吸引我。但是公司位置选的极好，倚山傍水。还有，老总的谈吐不错，很有知识的样子，又有一定魅力，成熟男人的魅力。两个原因，一半一半，我决定做了。

工作不难，就是有点忙，就这么点人嘛。椎子放在哪里都要冒头的，这是我很小时候看到却一直记到现在的话。我很快就冒头了。主管是个小男人，不光只个子小，心眼也小，能力是有点，但是做事太不公平，也不是很负责。终于在一次赶活的最后阶段，检查出了质量问题。我们在加班，他却跑回老家逍遥去了。找不到他，就惊动了老总。我们加了个通宵，终于改完了大部分的错误，然后下午回家补觉。第二天再上班的时候，我和另一个MM升了职，那个主管被老总请回家了。

其实那个主管一直满得老总信任的。据资历老些的员工说，他也不是没犯过错没被投诉过，但老总一直坦护他。这次居然这么大动作，有点意料之外。也许以前一直没有人能够接替他，现在有了人选，偶，所以他的工作就到头了。

几个核心开发人员，那时候都是兼职的。看到他们的时候倒也没什么特别激动的，能干的人到处都有。只是没想到后来其中一个会和我走的那么近。公司的结构也逐渐清楚了。原来老总是老板之一，几个老板全是美籍，应该都是上一辈有些来头的，其它几个主要待在北京。公司在上海也有机构，老总经常会来往于两地。

升了职，和老板的交互也多了。

在网易上乱逛，看到一篇文章“IT女人难 三十五岁的IT女人难上难”。

我，30岁。在生日将临之际，也回头看看自己的人生吧。

上中学的时候，就跟好友说，偶会30岁结婚（结果真的在这一年嫁人了）。学生时代，算是个比较叛逆的女生。喜欢金属，喜欢看血腥杀戮的电影，喜欢看武侠小说，喜欢画了黑色的妆去泡吧，喜欢穿样式简单全部是黑色的衣服。我知道我长的不错又聪明、愿意的话可以非常讨人喜欢，却固执的认为最喜欢的人一定伤自己最深，宁愿冷漠的看人拒人于千里之外。除了最好的两个朋友外，几乎独来独往。

这两个朋友，一女一男。女生排前面，因为是最好的朋友。虽然性格、背景都不相似，但是奇怪的我们就是感情好，完全的铁杆。无话不谈，基本上没秘密。这种感觉确实很好。我们还交换自己写的纸片。谈话仍然不能表述清楚的都写下来，不满、失落、希望，长篇的写。我喜欢鲁迅，写东西也一如他的尖刻，被语文老师批评还以此为荣。发梦的年纪。男生排后面，因为我们之所以亲近，是他努力不懈追来的。应该属于一般意义上的男友吧。那个时候，学校打架是经常的，学校内部、校校之间、学生与校外的小痞子，总之是比较乱的。他可能因为个高又义气，是有点小名气的。不过我没见过。

上大学后，对金属更加狂热，对事情看得更深入，开始愤世忌俗。金属给我所有需要的感觉。黑暗、毁灭、愤怒、嘲讽、厌世。。。成熟使我对人显得热情，虽然心里却更冷漠。因为我是本地人，我被任命为副班长。可是我在所有与学习无关的事上都没有起到好的作用。晚上泡吧晚归翻墙入校，穿奇装异服，交男朋友。。。其实这些在今天来看好平常，但是90年代，那是足以象今天的同居、吸毒一般为学校所震惊，连我的父母都找过了。但是我的成绩真是很好，学计算机的女生很少，好象一般人也认为理科应该是男生学的好，可是我的成绩无论是高数还是程序设计、机械制图，都是属一属二的。当然，也有可能是那些男生太笨。奖学金、校外实习，样样有我的份。可能是因为这个吧，老师也没拿我怎么样。

但是我对性一直很排斥，无论我喜欢的歌手们如何放荡，无论晚上的那些朋友如何自由，我始终对此保持相当远的距离。后来我认为，那时候的我是有同性恋倾向的，因为更喜欢看女人，尤其是性感女人。只是那时候不太懂这个，连男同性恋都只是欧美歌手的花边新闻里隐约提到，别提女同性恋了。当然男朋友是有的，谁叫偶PP呢~但是偶只觉得他们都好傻，好听点叫天真善良，不过分的玩玩而已。

再然后就毕业了。跑到国企干了一年。一个狂热金属、愤世忌俗的人在国企里的结局是可想而知的，偶逃离了。在人才市场，一家香港的食品企业招聘管理实习生。我喜欢这个名字，它意味着靠你的表现决定你能做什么。而幸运的是，这家公司派在当地的老总是个30左右、外表相当不错有点中性的女人，而她就在招聘现场。那时候的香港人，还是一个漂亮会打扮的女人，在众多的本地人中间，简直就是把“我是香港人”写在了额头上。所以我把简历直接递给了她，在她看我的第一眼，我就相信我会应聘成功。

随后就是两年的跟班生涯。我的职务是。。。天，我忘了是什么了，反正就是广告策划那类。老总在这人生地不熟的地方，需要有自己可以相信又合得来的人。一开始和她并不是很接近。一直到总助登场。总助是个比我大几年的女生，高干子女，看她的装束、谈吐就知道出身不同了。总助和我挺合得来，老总又和总助很合得来，于是我们三个人就都合得来了。

她们都是见过世面、眼界很高、小资倾向严重的女人，跟她们久了，我也知道什么叫品味了。大概算是完成了愤青到小资的入门课程吧。离开她们之后，个性及工作的原因，决定精致的生活方式与我只是擦肩而过，只有香水，还有一些潜移默化的细节留了下来。由于公司有一定的背景，我也了解到那段时期一些事情的内幕，90年代末，是比较多事的时期。我对政治的态度很简单，它黑暗，但是国家，尤其是中国，需要强权统治。所以我看不惯，但是我接受、我支持。

两年期间，我的部门经理换了几拨，我却一直巍然不动。最后一段时间老总开始无心管理、一门心思要返回总部的时候（离开中心太久，管你原来是老板多信任的人，也要有危机感了），我接管了花钱大权。虽然是小公司，一年却也有几百万的广告费。这可是90年代的几百万。花了这么些钱，可是我从来没从这个数字里挖出一小块来放进我的口袋。倒也谈不上忠心或者善良什么的，只是个性如此，不是自己的不要。

漂亮老总终于运动回总部了，换了个小地方出来的人做老总。虽然我的棱角已经磨去了些，可是仍然没能挡住我看不起这样的男人，当然他也不能容忍前老总的跟班。于是冲突、冲突。。。我又逃离了。

以后的日子我经常怀念那两年。有人罩着，我很悠闲。有人比我强，我有很多可以学习的东西。有人比我的眼界开阔，我看到了很多原来看不到看不清的事情。虽然这两年我的专业知识只用在了OFFICE软件的应用上，但是它对我性格、生活态度的养成有极重要的作用。

顺应热潮，跳到一家听起来很大的网络公司。结果发现完全不是那么回事。做了极短时间的市场，从此断言自己永远做不了这个职业。这个更象小插曲的工作，历时两个月左右就爽快的结束了。

然后就是现在这家公司。

烦燥的无以复加,满脑子的新建审核修改入库...为什么工作流程如此复杂,为什么以往系统都没有文档.为什么为什么为什么,如此多的为什么又是为什么.

天哪~~```

还好头发够长,可以咬来解解气.否则要我怎么办.发现留长发除了美观之外的另一个好处.

不明白,流程的自动推进,非得用这么多的层次这么多的状态吗?不相信这么复杂的系统可以在工作中被完全的正常使用.一定会被用户抱怨的.可是做出来的就是这么个东西.那么它一定是有其特殊性,而非通用的.特性/共性...理不清.

当我们转向.net,转向B/S的时候,这些,还是要提醒团队注意的.

 

避免网络应用程序的10个安全错误

----ZDNet

 

我最近被要求写一篇关于网络应用安全错误的文章。这是非常容易的；以下就是我经常看见的一些错误：

1. 盲目地相信在URL中从cookies和参数中返回的信息。
2. 不检查从屏幕输入的内容
3. 提前确认帐号
4. 不限制用户的行为
5. 错误创建网络文件夹的访问权限
6. 获取敏感的信息
7. 安装网络服务器的范例（如同IIS默认安装一样）
8. 忘记修改数据库后台的默认密码
9. 没有下载安全补丁
10. 开放网络管理的端口

以下是对于前五个常见错误的简单描述：

相信但是要确认

“相信但是要确认”这句话是我所尊敬的一个老板的座佑铭。对于网络开发者和程序员而言，这个座佑铭应该被很好地采纳。当cookies和URL参数给开发者们带来了很大好处的时候，传送过来的数据应该需要经常验证。

许多和网络有关的商业人士很难接受使用这个观点来解释“购物卡弱点”，所谓的“购物卡弱点”就是源于一些人通过修改购物卡上的金额而带来的问题。购物卡无非就是一个基于文本的cookie。通过检查，服务器可以计算出在cookie上的金额总数。假设――如果客户对价格有着完全的控制能力。可以相信，如果服务器没有验证数据的能力，商家们就会经历一次强烈的打击。

最好的检查方法就是清除所有的cookies，运行应用程序，查看写到磁盘上的cookies。我经常查看我的cookies，确保我的敏感信息并没有存放在其中，所谓的敏感信息如用户名和密码。

命令等同于控制

我曾经看过一个系统，它通过URL参数传送程序控制。当我在查看源代码的时候，我注意到了一个很平常的线程。系统级的命令被嵌入到URL中，如下：“action='do something.'”

在测试中，我创建了一对用户的URL，看看系统将如何处理。结果，我就可以通过我传递的命令（"action='cat xxx >> /etc/passwd.'"）来控制系统，当然，这是系统没有料到的。

如果你的参数是通过URL来传递的，将它们分裂到无效的内容中去。设置一些参数限制，这样如果有一个预料之外的值传递过来，你的应用程序就可以很好的处理它。这也使测试变得非常的容易――调整URL的地址栏，看看应用程序将如何处理。

请务必检查

我经常看到有的区域的输入数据没有经过验证。对于缓冲溢出和SQL攻击者来说，这是一个绝好的机会。在测试中，我打开记事本，创建一个超过500个字符的字符串，然后剪切并将它们粘贴到密码行区域。如果系统不限制输入的字符串，那么大多的系统都会死机或崩溃。

接下来我要通过将嵌入的正确条件（如，"OR 'x'='x'"）填充到密码输入区中来测试确认规则。很多的系统都会允许未授权用户访问，由于SQL的声明的创建方式的缘故，使用一个“OR TRUE”条件就可以愚弄系统，使系统允许非授权用户进入。这里是一个可以操纵的SQL声明的例子
Select userid, passwd from USERS where userid = :uid_entered and passwd = pwd_entered

假设用户在用户名中输入admin，而在密码域中输入"OR 'x'='x'"，SQL声明就会将这个用户名和密码解释成"select userid, passwd from USERS where userid=admin and passwd=password OR 'x'='x'”。这显然不是开发者所希望的。

放在门口的垫子下的钥匙

同样，对于我看到的使用系统帐号来进行预验证的登陆方式访问应用数据库也感到非常的惊讶。许多的网络应用程序在它们自己的应用数据库中存放了用户的验证内容（也就是用户名和密码）。为了要验证用户的访问权限，你必须要登陆到数据库上去，系统通常通过我所说的“预验证登陆帐号”来处理这个验证；例如，系统作为“admin/admin”登陆并确认用户输入的用户名和密码是否在数据库中相匹配。

值得注意的是，我遇到的每个预验证帐号都是“admin”类型并且具有高级的访问应用程序的权限。为了使得网络应用程序对帐号的密码有可见性，它们或者将用户名和密码存放在一个Webroot的文本文件中，或者直接将这些用户名和密码嵌入到开始的页面中去，这就使得危险进一步的加大。因为无论是哪一种方法，一个恶意的用户都可以很轻松地获取到密码。这个方法就如同将大门的钥匙藏在门口垫子下面，或者是将备用的汽车钥匙放在(汽车挡风玻璃上方的)遮阳板上。这种错误使得人们很容易就能够进入网页应用程序。

从左边入手

另一个我感兴趣的测试就是让一个应用程序的管理员合法地登陆，添加任意一个管理页面书签（如：“添加一个新的用户页面”），然后注销。我所测试的就是在管理员注销之后打开浏览器，并点击刚刚创建的那个书签。令人惊奇的是，大部分的应用程序都会自动赋给我管理员的权限。

另外一个技术就是查看被注释掉但却没有删除的代码。我以一个客人（guest）的身份登陆－－或者以任何受限的用户身份登陆――然后试图访问这些代码。再一次发现，许多的代码都保留在基线之内。

一般而言，开发者们都会在开发的时候创建一个开始的页面，这个页面并没有什么用途――一般是一个登陆测试环境。当要退出系统的时候，老练的网络程序员就会注释掉最初的调用，或者将页面重命名后存放在Webroot中。

同样，我检查了代码，确认是否会有多用户登陆或启动窗口的情况，测试哪一个可以允许我可以通过不输入确认信息登陆系统。同样，我会试图操纵外部的控制，特别是当开发者放置了导航栏。通常，我会去查看一下浏览器的历史记录或者是缓存记录，检查其它用户访问过的网页。如果那些暂时的Internet文件没有被清空，那么它们就可以提供大量有用的信息。如果应用程序希望我从右边入手，在测试的时候，我就会测试它是否能够防止我从左边入手。

我可以吗

一般的开发者对于丢失许可集不负责任――除非应用程序依赖于它们而创建。例如，如果一个网络应用程序需要一个特殊的路径可以允许所有的人操纵（读写），或者是只可运行而不可读写，这个应用程序提供了一个很好的场所来隐藏（可能是触发）恶意的逻辑。

许多应用程序都有存储暂时文件的路径。通常，我会试图通过修改URL得到许可而访问网络服务器上的文件夹。如果应用程序提供特别的查询能力（有可写文件夹存储结果）。我将会试图传递一个可执行文件，并从浏览器中调用它，观察它是否能够执行。

如果应用程序能够提供上传数据的能力，我将测试它的执行许可条件。很少有系统允许执行网络文件夹，也不允许用户在服务器上运行可执行文件。如果我可以在应用程序外进行处理（通常我是可以的），任何的一个进程都由特殊的帐号所拥有，如"oracle"，"root"，或"system"，并且只有它们的拥有者有访问的权限。那么，如果应用程序使上传数据变得简单时或者造成数据上传后就不能限制用户访问数据的情况时就会出现潜在的问题。另外一个常见的错误就是在上传的时候仅仅需要很低的权限。

避免弱点的出现

当这个列表没有包含全部错误类型的时候，我就曾经看见过有些开发者在创建网络应用程序的时候出现的错误。开发者和测试人员希望获得关于一般弱点的更多信息，可是却很少有这方面的内容。我强烈建议所有的开发者门阅读OWASP2004的报告。你也应该阅读SANS 的头20条内容。它虽然没有明确指出网络应用程序的错误所在，但是它会给开发者提供一个如何防御的理念。有了这些知识的装备，你就应该能够避免最为寻常的一些"gotchas"。

这是数据库文档的相关注意.但对于业务数据字典,还是没有.

 

文档化数据库项目以捕捉相关信息

----ZDNet 

在数据库开发阶段对其进行文档化，可有效地捕捉组织架构、数据对象和其他相关信息，以便将来参考。

这个文档的形式是多种多样的，包括数据字典、数据库管理员指南、数据库体系结构信息以及数据库功能规范。本文用“数据字典”这一术语来指代数据库文档。虽然你目前的数据库文档可能没有使用这个名字，但基本原理是一样的。本文有助于你更好地理解自己的数据库文档。

开发数据库文档

一个数据库文档的读者包括：

• 数据库结构师
• 数据库开发者
• 数据库管理员
• 生产支持人员
• 质量保证人员

开发数据字典的实际过程要由一个多功能团队中的主力队员来完成，包括数据库管理员和/或数据库结构师、业务分析员以及技术作家。虽然你的公司在分配数据库文档开发人员时有所不同，但数据库文档的核心必须来源于构建数据库的那个团队。

数据库管理员可从数据库本身提取必要的数据字典信息。在许多关系型数据库管理系统（RDBMS）中，数据字典是作为一个电子文件提供的。DBA和数据库开发者可从文件中提取有用的信息，包括：

• 列出数据库中包括的所有文件。
• 数据库中包括的每个文件中的记录数。
• 每个数据库字段的名称和类型。

数据字典中包括的信息在普通用户面前隐藏，防止内容遭受破坏。数据字典在数据库中发挥的是管理职能，其中不包括任何实际的数据库数据（虽然RDBMS要求一个数据字典来访问来自数据库的数据）。

业务分析员和技术作家由于具有印刷技术文档方面的专长，所以在数据库文档化过程中也能发挥关键作用。虽然DBA提取的信息非常重要，但它仍需正确地表示，并向内部和外部的客户群体传达。除此之外，自动化文档并不是万能的，所以仍需业务分析员和技术作家提取被遗漏的技术信息。当然，业务分析员和技术作家不能是当前项目的门外汉，他们必须完全投入这个项目中，而不能临时抱佛脚地最后突击一下。

要包括到数据库文档中的典型元素

在你的数据库文档中，应考虑捕捉以下信息：

• 数据元素编号
• 数据元素名称，这种名称通常不能重复（名称通常在设计阶段决定，并要受到“需求收集”阶段的一些影响）。
• 数据元素的简短描述
• 数据元素的安全性分类（各单位通常对安全性分类有具体的要求。数据开发团队和公司的安全团队对此都有特别的要求，所以应参加到安全性分类中来。对安全性分类的其他影响包括文档要求、功能规范以及数据库的设计文档）。
• 与特定数据元素具有重要关系的相关数据元素的列表。
• 基于数据库架构和/或RDBMS所提供的技术名称的字段名。
• 代码格式，包括任何必要的特殊表示法，以及数据类型的格式和大小。
• 默认的数据值（要在此列出所有存在默认值的变量）。
• 元素编码，对编码和验证规则进行了解释
• 对其他文档的引用，列出该元素和数据库文档及数据字典中文档化的其他元素之间的任何验证规则
• 数据库表引用
• 元素的数据源
• 数据元素的有效日期
• 历史引用
• 扩展引用
• 数据元素版本

上述提纲罗列了通常要包括进来的文档小节，你可根据自己的实际需要进行修改。

还要为数据库的表撰写文档。使用SQL命令help table，就可为一个SQL数据库提取这些表信息，包括：

• 表名
• 数据库或表所有者姓名
• 数据元素列名和详细资料
• 所有元素的键序
• 数据库索引信息
• 技术性表组织
• 重复行信息（是否允许重复行）
• 数据元素列表
• 表安全性分类

计划数据库文档时，还要考虑到数据库架构。可利用Visio等工具开发数据库架构的一个图形化表示，以便将其包括到印刷文档中。

自动化数据库文档化工具

有多种自动化的文档化工具可供选择，例如：

• 由A&G Software开发的AGS SQL Scribe Documentation Builder Version 3.0可自动生成Microsoft SQL Server数据库文档。
• 由.com Solutions公司开发的InstallGen可自动生成Oracle数据库文档。

Microsoft Visio Professional 2002也是一款非常流行的数据库文档工具。它包括以下模板：

• 数据库模型图
• Express-G
• ORM图

最佳做法

数据库文档的“最佳做法”是综合运用自动化工具以及有经验的业务分析员和/或高级技术作家的帮助。有这些人提供帮助，再配合数据库结构师、开发者和管理员的专业技能，就能保证文档符合所有人的需要和希望。

无奈的选择,最近foxmail不知道中了什么毒,只要开机第一次启动,就把我的IE主页改为不知道什么地方,那个网页还从来不能浏览,于是就转到某个搜索引擎.查了查找不到有关的文章,又不想弄些七七八八的软件来管着我的注册表,于是只好用MYIE了.用了才发现,还挺顺手~支持各种外挂工具及插件皮肤什么的也就一般,倒是鼠标操作快捷组什么的,功能都挺贴合实际需要的.与以往的浏览器果然有较大的区别.

从需求来说,这些是最终用户的需求,并且是在使用中积累的需求.从需求的收集来说,这种需求是比较难收集的,除非建立一套完整的反馈机制,否则只能靠日积月累口耳相传.前段时间从各项目经理收集的情况来说,各项目的差异相当大,仅就我所负责的项目,就与其它所有的项目完全不同,各有各的一套,仅能提炼出非常少的共同点.偏向任一方,都不足以满足全体.而且,项目经理的记录本身就是不完整的,这点可以从我推往全体.所以,依靠项目经理的记录来获取客户/用户需求,都至少是不完整的.应该寻找更广泛更直接更中立的来源.

目前来说,论坛应是最主要的来源,但是公司的论坛使用率还不高.一是用户用论坛的不多,更愿意通过支持电话;二是即使使用论坛,多数用户也不会发表建议的言论,投诉的比较多 :( .需要引导.而且,整理转换也会比较复杂,"林子大了,什么鸟都有"~

同时,技术支持和考务也应是一大来源.技术支持接触到的大部分咨询抱怨都可以转化为用户需求,功能\操作\控制度,但很多都被浪费掉了.因为技术支持的职责是尽快解决问题,而不是记录反馈,记录详细的情况确实很费事,记录准确更难,只有建立成为制度,使用有效指标来考核,才可能实现转化.

考务更有其特殊性,作为客户的代理人,他们在运作中产生的需求实际上就代表着客户的利益,基本可以等同于客户需求.而他们在与用户交互过程中所产生的需求,也同样可以转化为用户需求.

思考一下公司的系统,应该说只满足了最基本的业务需求,套用生活指标,充其量也就是个温饱,想奔小康,还真有点磕磕绊绊的.问题在于公司的主要方向在哪.究竟是进一步加快开发新客户,还是放慢节奏,更好的维护目前运行中的系统.人力物力有限,不可能两者兼顾.

昨天的会议有人反对现在的方式,认为没有框架性的结构就进行用例及UI编写是混乱低效的.

但是我认为我们的方式还是正确的,因为我们这个项目的特殊性,就是没有人能够说出具体的需求,即使是目标客户,连业务规则都是我们在定,何况是功能需求.一切都要讨论,没有具体的讨论就没有具体并且相对准确的需求.而没有用例/UI的编写,就不可能有具体的讨论.

而且我们也并不是没有框架,只不过框架产生的时候就随时准备拆掉重来.首先我们自上而下的整理流程,做出了系统用例分析,也可以说是最初的框架;然后是自下而上的编写功能点,可以说是填肉.这步中的"自下"就是我们现在在做的用例和UI,这个做完才能再"而上",合并与集中.到开发测试,还会有若干轮这样的循环.

框架是什么,不过是个模糊的影子,如果一开始就能定下框架,那一定是个倾斜的框架.如果需求这么好掌握,所有系统的返工就不存在了.

在这个项目中,比较大的一个遗憾是编写用例的人应该是运营部门的同事.对于开发人员来说,一方面不太理解运营流程,一方面太多的关注实现,所以重点明显的不在于保证数据的完整性和功能的易于管理.这是一个很大的阴影.但是,运营的同事又没时间没能力来做这件事,两难.

 

CommonSubBehavior(186) states that you should consider creating an <<includes>> relationship between use cases only when two or more use cases share a common set of actions. The purpose is to consolidate common behavior and simplify your model by reducing redundancy.
InterruptsAsExtensions(191) recommends you consider an extension use case only when an alternative interrupts a number of steps in a scenario. This technique helps simplify the model by consolidating the related interrupting actions in one use case, rather than dispersing them across several alternative courses of action.
PromoteAlternative(196) suggests that you may also want to use extensions when you have some important alternatives that you may want to emphasize. In this case, you can “graduate” these alternatives into an extension use case so that they stand out. You should
use this technique sparingly, so that you don’t conflict with the guidelines described in InterruptsAsExtensions(191).

 

SharedClearVision:

Prepare a statement of purpose for the system that clearly describes the objectives of the system. Ensure that this vision supports the mission of the organization, and freely distribute it to everyone involved with the product.

Include:
• the objectives of the system,
• the problems that the system is solving,
• the problems the system is not solving,
• who the stakeholders are, and
• how the system will benefit the stakeholders.

A characteristic of many successful projects is the
appointment of a single person who champions the vision of the system and is responsible for maintaining the consistency of that vision.
Validate the vision and seek support for the vision by obtaining advice from those who will be affected by the system (ParticipatingAudience(50)).
Strengthen and constrain the vision by clearly specifying what is outside of the system and what is part of the system (VisibleBoundary(101)).
Ensure the vision is supportive of the stakeholders’ mission and does not work at crosspurposes.
A truly excellent system vision will fail if it defines a vision that works against the organization’s mission.
Finally, when there are changes to the vision, ensure that all project participants are immediately aware of the changes.

VisibleBoundary:

Establish a visible boundary between the system and its environment by enumerating who and what interacts with the system.

The VisibleBoundary(101) limits and supports the SharedClearVision(95) by:
1. specifying what external systems and personnel the system must collaborate with,and by
2. specifying what resources the system has available to it to accomplish its purpose.
In the early stages of development, the visible boundary may be fuzzy because the vision for the system may not be clear. Start by putting a stake in the ground and document the system boundary based on the information you have available to you. As you develop your use
cases and learn more about the system, you can refine and sharpen the system boundary i.e. SpiralDevelopment(66).

ClearCastOfCharacters:

Identify the actors and the role each plays with respect to the system. Clearly describe each of the actors the system must interact with.

For each user identify and list the services they require from the system. Try to organize the services into cohesive sets and name those sets. Look carefully for users that have overlapping sets of services and collect those services into sets. Examine the sets of
collected services to see if they are complete and are not missing services. These sets are the actors of the system and represent the roles entities play with respect to the system.
Give each actor a clear crisp noun or noun phrase name. If you cannot provide a good name for the actor then the odds are you have not identified an actor. Write a description for the actor specifying the services they require or offer to the system.
In the early development phases it can be difficult to find the roles of the actors. Finding the roles of the users is often an emergent characteristic of creating the use cases. So don’t get bogged down if you cannot find all of the roles right away, because they should naturally emerge as part of the SpiralDevelopment(66) cycle.

UserValuedTransactions:

Capture the smallest set of goals that identify the valuable services that the system must deliver to the actors to satisfy its statements of purpose.

Ideally, a set of use cases should contain all of the information necessary to depict a system but no more. Each use case should describe some unique, essential service that is valuable to at least one user or stakeholder.
Use the ClearCastOfCharacters(105) and SharedClearVision(95) to identify those services that the system should provide. Define as many valuable services as you can for each actor in your cast of characters that help them reach a goal. Being unable to identify any service
for an actor may indicate that the actor might not represent a valid system user and you should consider removing them from the cast. Conversely, if you identify a service that doesn’t map to an actor in your cast, it may indicate that you have not identified all of the
actors.
For each service that you identify, ask “What value does this service provide to the user or stakeholders?” Get rid of those services that fail to add value to the system.
Users and stakeholders prefer to see the bottom line rather than an itemized list of ‘CRUD’ style services, so examine each service and determine whether each service stands by itself or is part of a larger, more valuable service. Fold those services that cannot standy themselves into more comprehensive ones that address one key objective, and eliminate duplicates.
Write use cases around these goals. While you want to minimize the number of use cases in your collection, each use case should be a cohesive unit that describes one and only one key concept between an actor and the system, a CompleteSingleGoal(132). Describe this collection in sufficient detail to adequately describe its purpose, yet be high level enough so as to be insulated from simple changes.
This singleness of purpose does not prevent a use case from addressing more than one goal, as long as the use case is cohesive and achieves a unified purpose. For example, a highlevel use case can reference several subordinate use cases in an EverUnfoldingStory(117), but these use cases must work together to accomplish a common purpose.
Note: In BreadthBeforeDepth(63), the actor names and the names of the user valued transactions make up the original depth to which use cases should be taken before SpiralDevelopment(66) is applied.

EverUnfoldingStory:

Organize the use case set as a hierarchical story which can be unfolded to get more detail, or folded up to hide detail and get more context.

A good set of use cases contains several cohesive levels of related use cases that completely describe the system in different levels of abstraction, where each subordinate level closely resembles the level above it, albeit with greater detail.
A good way to describe unfolding use cases is to include several subsets of use cases in your collection, where each subset describes the system at a different level of detail. In his book “Writing Effective Use Cases” Alistair Cockburn suggests three levels of use cases:
Summary Level Use Case is one that takes multiple user goal sessions to complete, possibly weeks, months, or years.
User Goal Use Case satisfies a particular and immediate goal of value to the primary actor. It is typically performed by one primary actor in one sitting.
Subfunction use case satisfies a partial goal of a user goal use case or of another subfunction. Its steps are lower level subfunctions.
The higher-level use cases provide the context for the lower level use cases. Or more simply, higher-level use cases answer the question “why is the actor doing this” for lower level use cases. The lower level use case answers the question for the higher-level use cases “how is this going to happen.”

Tradeoffs and Collaborations:

The first level of organization is as a set or collection (see Figure 1-21), and we want to organize its contents in a friendly, easy to use manner that allows the user to see the system as a whole, then shift their focus to its individual pieces. A good way to do this is to describe the system as an EverUnfoldingStory(117), which consists of several complete subsets of use cases that present the system in increasing levels of detail. Each of these subsets can stand alone, and allow the reader to examine the system from their particular level of
precision, yet each subset expands into the next level of detail, allowing the reader to ‘zoomin’ on the parts they find interesting. This style allows some readers the ability to examine the system from the 50,000-foot level, as well as focus on some of the low-level details of the system as well.
Creating an EverUnfoldingStory(117) requires the writers to have a SharedClearVision(95) of the system, so that they can clearly describe its purpose, and inform their audience as to what the system will and will not accomplish. To successfully reveal this vision, the writers
need to clearly answer three questions. We have identified three patterns to help them do this. First, we need to know who will use the system. We need a ClearCastOfCharacters(105), describing everyone’s role in the system. Second, we need to know what actions the users expect the system to do, actions that are UserValuedTransactions(110). Lastly, we want to know where these actions are meaningful to the user; we want to know the system’s VisibleBoundary(101).

 

快速浏览本章节,并应用于正在编写的文档中,肯定有问题,渐进吧~`

非程序员 33

可是几乎没时间去研究ROSE,真是郁闷!明知道问题在哪里,却没法解决,确实是...非常非常郁闷的事!!

周末还要加班,有效用例模式也没看完,又塞进来本分析技术,真是...头大~````

--非程序员 33
1. 倾听的能力。积极倾听包括排除干扰，保持专心的姿态和眼神接触，并重复要点来确认你己经理解。你需要抓住要点并从字里行间推断出对方犹犹豫豫没有说出来的东西。了解对方喜欢什么样的沟通方式，尽量避免把你的个人理解强加到客户身上。
2. 访问能力。大多数需求输入来自讨论，因此一名分析员必须能够询问正确的问题。例如，用户一般会把精力集中在正常的、符合期望的行为上，而每个程序员都知道需要大量代码来处理错误，可以问类似这样的问题“如果这样，会发生什么事情”或“会出现这样的问题吗？”Donald Gause和Gerald Weinberg在书中[2]描述了“context-free questions”的技术。
3. 分析能力。有在不同层次进行抽象的能力。有时你需要从高层往下钻到细节，有时需要从某个用户的特定需要泛化到适用于整个用户类别的需求集合。评价各种从不同来源收集到的素材，调和冲突，从用户的需要中分离出真正想要的，并把解决方案从需求分离。
4. 协调能力。涉众需要需求工程师作为中立的协调员，协调员需要强的提问和观察技巧，以帮助团体建立信任、改善业务人员和技术人员之间有时会出现的紧张关系。Ellen Gottesdiener的书[3]中提供了协调员的建议宝库。5. 观察能力。在持续观察用户做工作或使用一个应用系统的时候，你可以推断到一些微妙的东西，这些东西可能在讨论的时候没有涉及。这样就揭示了新的需求领域。6. 书写能力。你为顾客、营销人员、经理的主要交付物是书写好的规格说明。为了完成这个任务，你需要有坚实的(自然)语言能力。力争做到清楚，避免含糊词语和语法错误。
7. 组织能力。你会面对一大堆在启发和分析中得到的混乱信息，快速地把它们组织起来，把碎片拼成相关的整体。这需要高超的组织技巧，还有耐心和韧性。
8. 建模能力。从流程图到结构化分析模型(数据流图、实体关系图等)到UML标记，需求分析师的工具箱里应该有这些画图工具。在和用户交流的时候，一些这样的技巧是非常有用的，和开发人员的交流也一样。你会经常需要教育其他涉众这些技能的价值以及如何阅读它们。
9. 交际能力。你必须能够使有不同兴趣的人一起工作。你应能自如地和组织中不同级别的个体交谈不同的工作，你可能还需要和分布的团队交流，它的成员分布在不同的地点，时区、文化、语言都有区别。
1O. 创新能力。分析师不只是一名抄写员，顾客说什么他就记什么。James Robertson[4]建议最好的分析师应提议需求，分析师可以构思创新的产品功能，设想新的市场和业务机会，想出能够使顾客震惊和高兴的好方法。一名真正有价值的分析师能发现创新方法来满足用户一直不知道自己已有的需要。
11. 领域知识。事先拥有一定的领域知识，才能使以上的能力发挥出来。

BreadthBeforeDepth:

Conserve your energy by developing an overview of your use cases first, then
progressively add detail, working across a group of related use cases.

Start writing your use cases by outlining them before adding detail. Identify candidate use cases
by associating a meaningful goal for each actor, defining a use case for every combination
(UserValuedTransactions(110)). Using the goal, derive an IntentionRevealingName(144) for
each use case. Once you feel that you have defined a fairly complete set of use cases, work
through your set, refining it, combining equivalent use cases and eliminating unnecessary ones
(see MergeDroplets(211), RedistributeTheWealth(206), and CleanHouse(216). The resulting
set of system goals provides a fundamental, shared understanding for the stakeholders and helps
reduce the amount of refactoring required later on.

SpiralDevelopment:

Develop use cases in an iterative breadth-first manner, with each iteration progressively
increasing the precision and accuracy of the use case set.

Working along BreadthBeforeDepth(63), pause when you have listed the actors and their goals,
and work with that list for a while. Use the list to set up the project plan, estimate work, prioritize
the use cases' value, even to help set up the development teams.
Continuing with BreadthBeforeDepth(63), choose a working subset of the use cases to expand,
and pause again when you have a set of main success scenarios, to review the purpose of the
system. Take the opportunity at this moment to review the use cases. See whether you need to
MergeDroplets(211), or CleanHouse(216), or in any other way improve the structure. You may
find yourself revising the list of actors and goals at this point.
Finally, completing BreadthBeforeDepth(63),you will probably find yourself revising your list of
use cases one more time when you start working out the extension handling behavior for your
use cases. It often happens that new use cases turn up at this point.
Key to the successful use of iterative development, of which SpiralDevelopment(XXX) is an
example, is knowing when it is time to stop. Stop as soon as you are sure that your use cases are
good enough to meet your stakeholders' needs, so that you can avoid the law of diminishing
returns. QuittingTime(71) provides a set of criteria that you can use to determine that point.

SpiralDevelopment and UML Models
- Diagrams based on actors
- Diagrams based on similar functionality
- Diagrams based on abstraction level

MultipleForms:

Select the format based on the risks associated with the project and the preferences of the
people involved.

Use cases are only a tool for describing a system’s behavior to your
stakeholders and developers, and therefore only need to meet their needs for precision and
content. Any more information is unnecessary.

TwoTierReview:

Hold two types of review. The first is done by a smaller, internal team, possibly many
times. The second is done by the complete group, perhaps just once.

First, review the use cases internally to verify their readability, implementability, precision and
accuracy. These “inner” reviews can be informal desk-reviews, formal meetings, or a combination
of both. Any kind of review is appropriate as long as it allows the reviewers to catch errors and
verify that your use cases are sufficient as far as they are concerned. One of the purposes of
these initial reviews is to eliminate the “noise” caused by spelling, grammatical, and formatting
and technical errors, which when left uncorrected are distracting.
You may need to hold several of these inner reviews when the system is large or overly complex.
Because people tend to lose interest in detailed discussions outside of their own area of interest,
consider holding separate group reviews for different functional areas when formally reviewing
use cases aimed at a large, disparate customer base. That way, each group of stakeholders can
review the use cases in depth from their particular point of view without distraction.
At the end of these inner reviews, the teams are asserting that it is QuittingTime(71), and that
the use cases are complete, correct, and as implementable as they need to be at this point. The
use cases are then ready for the bigger group to check.
Hold at least one meeting with the complete group once the use cases pass internal muster, to
review the system as a unified whole. Trust the first tier of reviews to validate the internal
workings of the system, so that the second tier can focus on how the pieces fit together.
The definition of "complete group" varies by project. It should be all the people who review the
requirements before development gets too far underway. In some cases it is just the development
team, sometimes developers plus an executive, sometimes it is the business analysts and the
lead programmers, sometimes it is users, executives and the entire programming team. The
purpose of the “outer” reviews is to determine:
• is this really the appropriate thing for the developers to spend time building (business
value check)?
• is this correct as a specification? (Are the business rules correct, and does it leave open
the proper allowed variations in implementation. Does it lock down the important
decisions - does it identify the appropriate set of open issues that can be handled later?)
• can the developers really build it?

QuittingTime:

Stop developing use cases once they are complete and satisfactorily meet audience
expectations.

You need to know what your goals for writing use cases are before you can determine if your use
cases are complete. It is important to be clear to all involved why you want to write use cases in
the first place, as well as what problems and risks you need them to resolve.
To determine if your use cases are complete, ask the following questions:
1) Have you identified and documented all actors and goals?
2) Has the customer, or someone representing the customer, acknowledged that the
use case set is complete, and that each use case is readable and correct?
3) Can your designers implement these use cases?
If the answer to any of these questions is no, then chances are you need to do more. Take
advantage of the core competencies of the organization and the shared knowledge of the
stakeholders to flesh out your use cases. Always keep in sight what the stakeholders need to
see in the model. Once the stakeholders agree that the use cases adequately reflect their vision
of the system, you are close to being finished, but it is important to satisfy all three questions.

WritersLicense:

Small differences in writing style are inevitable. Once a use case passes the tests for
QuittingTime(71), the writer can claim "writer's license" on small stylistic differences.

Write each use case so that it passes the following tests:

it follows the organization’s writing template and basic style;

it is logically correct;

it is readable to the end evaluators;

it is precise enough for the implementers to use.
Once the use cases meet these tests, allow the author to have final say on smaller stylistic
matters. Small differences in writing style are up to each use case writer; they can claim "writer's
license" to make any changes they think appropriate, while ignoring other style changes they feel
don’t add any value to the manuscript, or aren’t worth the effort involved.

For developing use cases, good process means balancing discovery versus writing, and content versus need.

 

终于看完了过程,基本与经验相吻合.实践起来就不知道效果了,至少同样是经验证明,理论应用于实践时总是有这样那样的无奈.但好的方法是应该被使用的,使用/失败中才能找到适合project & team的有效用例嘛~ :p

对照中文版和英文版,进一步证实了我的想法,翻译的不好.且不说中文水平,译者还画蛇添足的加进了自己的想法,甚至调整了原来的章节顺序,莫名其妙.

昨晚被逼迫着看了50页,进度有点慢,不过也因为翻译的不好,看起来有点别扭,有的句子得研究个半天才知道断句该怎么断,费劲.(又给自己找借口!)

关键点:识别系统为参与者提供以满足其业务目的的有价值服务(这句话多拗口,应该找原版看看!)

哈哈,找着了

Capture the smallest set of goals that identify the valuable services the system must
deliver to the actors to satisfy its statements of purpose.

果然意思不同!虽然不知道怎么翻比较好,但至少提供了比中文版多的多的信息.

 

用例模式表格和编写有效用例里的格式差不多,需要仔细对比一下.

开发模式可以看的快点了,比较组织性的内容.任务开始的时候再回头来仔细看吧,别让我给他们上课就行了,偶会脸红的说~``

结构模式会是重点,用例关系是新的内容,也是一直让我困惑的地方,要多看看.

前面说了很多问题,看来我的问题也是普遍性的,心里安慰多了~`希望看完这本书后,能找到度量的依据并写出有效的用例,目标.