导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:966496
  •  
摘录自微软的栾跃的软件开发项目管理一书和相关ppt
 
软件开发项目管理的十大精华指南
 
1.理解用户和市场要求,明确功能需求和范围
市场需求是产品立项重要依据,没有市场的产品是没有存在的价值的.用户需求是产品好卖的重点,是对市场需求的进一步细化,只有真正理解了用户需求才可能生产出符合用户需要的产品.

范围确定后可以出相关的需求规格说明书.详细的需求规格说明书应该包含输入,输出,流程,界面,业务规则等各种因素.对于采用面向对象的用例分析的需求说明书应该包含用例,业务对象模型,状态和活动图,用例的场景,前置,基本流,扩展流,异常流和业务规则,DEMO等各种重要的信息.
 
2.撰写完整的设计规范书,包括使用方案和界面
功能设计规范说明书是整个开发项目的中心指南.它是一份陈述或总结软件产品或系统的功能设计的文件.它由软件开发的设计项目经理或系统架构设计师撰写,向读者提供某一软件产品或系统的具体功能及其设计的详细叙述.软件工程的开发队伍以此为依据和规范进行软件产品或系统的开发.是整个项目做为蓝图的设计依据.
 
3.制定从下到上的项目进度时间表并对其进行追踪
WBS分解一般是从上到下进行的.针对WBS分解的估算一般既可以从上到小,也可以从下到上.或者两者混合使用.在我们安排进度表时候必须确定活动的依赖关系,确定每一个活动或任务的资源以及其持续时间,可以借助网络图等工具寻找关键路径,最终得到最终的进度表.并且设置相关的里程碑点和检查点,当进度计划确定并基线后.后期的进度跟踪和控制就要依据进度计划进行,并对偏差进行分析和应对.
 
4.以设计规范书为准制定构架设计及开发设计
以可以说设计规范中的某一些内容其实就是架构设计的内容.架构设计和模块设计都要以设计规范的约定进行.是对架构设计和模块设计进行指……
编辑 | 阅读全文(1257) | 回复(0),人月&神话 发表于 2007-7-17 13:18

2007-7-17 13:18 | 配置管理基础和重点

问题和场景
1.多人修改同样的源代码文件的时候,前者修改的内容往往被冲掉 (检入检出)
2.维护版本发布后发现两周前修改的一个Bug引入新问题,无法快速定位文件 (版本树,变更集)
3.新版本和维护版本都在做,有几个Bug修改需要单独部署,很难操作?(分支和Deliver)
4.程序打包或每日编译经常失败,而且在失败后无法快速定位到责任人 (检入检出,版本树)
5.设计人员依据进行设计的需求文档不是当初评审通过的版本 (配置项和基线)
6.无法在项目计划阶段定义出相关的该版本交付物 (配置项清单)
7.测试依据进行测试用例编写的需求和设计人员依据进行设计需求不一致 (基线)
8.项目经理无法清楚的知道项目成员任务是否完成 (任务,配置项和工作包对应)
9.无法在需求的时候生成项目的老版本 (基线,配置项一致性)

配置管理概念
PMI和CMMI都认为配置管理是包含了变更管理的。
 
软件配置管理是一门应用技术、管理和监督相结合的学科,通过标识和文档来记录配置项的功能和物理特性,控制这些特性的变更,记录和报告变更的过程和状态,并验证它们与需求是否一致。 (摘自IEEE定义)
                                              ……
编辑 | 阅读全文(1111) | 回复(1),人月&神话 发表于 2007-7-17 13:18
系统和软件体系结构 [ARC]
开发工具与技术 [DEV]
数据分析与管理平台 [DAT]
Web 技术 [WEB]
软件开发流程管理 [SDM]
系统互联 [CON]
Windows Server和企业IT架构 [SVR]
系统管理和运营 [MGT]
信息安全 [SEC]
Windows Vista 的创新技术 [WCI]
微软IT展示 [MSIT]
企业生产力解决方案 [OFC]
消息与协作 [MSG]
微软商务管理解决方案 [MBS]
 
SAAS和长尾理论-Software as a Service (SAAS)

现在微软也提出了SAAS的概念,软件通过托管服务的方式来部署而且是通过网络(Internet)来访问的.类似于我们原来说的ASP(Application Service Provider).以后软件就是一种服务,一种完全托管到第三方的服务。软件本身是免费的,企业无需关注关于软件产品的整个生命周期包括运行维护。
 
现在中国电信在做的商务领航,中国网通在做的宽带家园都是属于这个例子。中国还有数量巨大的没有实现基本的企业信息化的中小企业,关注长尾理论,是IT战略的下一个主要赢利点。
 
ASP这种模式对架构的重要影响就是商务应用必须是支持多组织,多实例的。而且需要提供强大的可配置,可扩展的功能。同时这些ASP应用用户都是百万级的用户,应用程序的性能和健壮性是一个需要重点考虑的因素。
 
 
需求分析的SMART原则(栾跃)

S  Speci……
编辑 | 阅读全文(1278) | 回复(0),人月&神话 发表于 2007-7-17 13:18

2007-7-17 13:18 | 版本发布和部署总结

对于项目的新版本和维护版本发布和部署一直是未控制的特别好的环节,特对相关步骤进行简单的总结:

维护版本的发布和部署
 
1.对于启用了Bug分支的情况,对于启用了Bug分支的情况,维护版本的发布和部署有两种方式。
 
a.修改的程序在Bug分支上面进行,而维护版本的构建在集成分支上进行:因此Bug修改完成后需要通知向开发分支和集成分支进行Deliver操作。但新版本开发修改到开发分支相同文件时候,存在源代码文件的Merge。这个时候Merge以Bug修改内容优先。
同时还存在问题是,当新版本发布的时候还需要从开发分支->测试分支->集成分支的Deliver操作,因此在新版本发布时候从测试分支向集成分支Deliver时候还存在一个代码文件的Merge过程。操作较复杂,无法完全交给配置管理员来做。
 
b.修改的程序在Bug分支上面进行,但维护版本的发布直接在Bug分支构建,在Bug分支进行基线。这种处理方式Bug分支上面的修改不用Deliver到集成分支上面,操作比方法a简化一些,但由于在Bug分支打包,因此对处理中的Bug必须是要不处理好,要不完全验证通过的,而不能把待测试或验证的Bug直接进行打包部署。
 
2.对于不启用Bug分支的情况
对于不启用Bug分支,则发维护版本的时候针对修改Bug的活动,单独进行从开发分支到测试分支的Deliver.在测试分支测试通过后再Deliver到集成分支上面打包和部署。
这种方法最大的问题是新版本的开发和维护期的Bug修改如果经常涉及到相同的源代码文件,则很难进行操作。只有采取将新版本内容临时注释掉,或者直接在集成分支Hajack进行修改。

新版本的发布和部署
对于版本的发布和部署涉及到产品集成,测试和部署等多个相关过程。产品集成PI也……
编辑 | 阅读全文(1329) | 回复(0),人月&神话 发表于 2007-7-17 13:18
对于聪明的人,只要一个字;对于快马,只要轻轻一鞭;对于写得好的程序,只要单独的一个命令。
 
设计一个千百万程序的操作系统很容易,要改变一个人的本性却困难得多。
 
开发前面的百分之九十需要一半时间,而另一半时间则用来完成最后的百分之十。
 
项目计划和公布的时间表,本身毫无意义。那些日期和项目进展的里程碑本质上不意味着什么。然而有一个秘密的时间表,它被所有工作于一个项目的人所理解。这个秘密的时间表从未被外界的关注所愚弄,也从未被操纵以迎合市场的方案。这个秘密的时间表总是被遵守,因为它反映了所有开发部成员之间的相互理解。当项目反映了这个现实时,程序会如期完成;当项目计划与此现实相矛盾时,程序会被延误。
 
有三种情况肯定会导致程序设计项目的失败。第一种情况是,主管此项目的经理对软件一无所知;第二种情况是,对程序代码负责的项目带头人对编写代码毫无兴趣;第三种情况是,编写代码的程序员是临时雇佣的,对项目缺乏忠诚。这三种情况中的任何一种都会导致项目的失败;三种情况同时出现,就必死无疑了。
 
一个程序的价值不能由它的宣传册的大小,或出现在大众计算机杂志上的整页广告的数量来判断。这些噪音越响,程序越不可能有用;真正优秀的程序不需要广告,用户会口口相伟。
 
一位初学者问大师:“程序设计的真正含义是什么?”
大师回答说:“饿的时侯就吃;困的时侯就睡;当时机恰当时,就进行程序设计。”
 
一位初学者问大师,“每当我在一套新的系统上编程时,必须学会一种新的语言。为什么没有一套标准呢?”
大师转身而去。“唯一真正的标准是死亡。”他说
 
“上个星期我准备劈些木柴烧火,但我的斧子又旧又钝。于是,我去五金店买了把新的。”
“这挺有趣儿,”……
编辑 | 阅读全文(1157) | 回复(0),人月&神话 发表于 2007-7-17 13:18

2007-7-17 13:18 | 最近的一些感悟

一天做三件事情,昨天遗留的事,今天的事,明天计划的事.做第一件事情的时被时间拽着.做最好一件事情的你主宰着时间.
 
爱思考的人不是吃一堑长一智,而是举一反三.
 
大多数人的职业选择就像买股票一样不尽如人意.想买而买的涨了,想卖而没卖的跌了.
 
讲成功学的书只有一本,成功者或大师讲时候就变成了圣经.失败者讲的时候就变成了扯蛋.
 
没时间做某事情60%是效率问题,40%是态度问题.
 
某人告诉你这10年准备做个什么事,可信度30%,这一年要做什么,可信度60%,这个月要做什么,可信度90%
 
什么是独立期,就是从正确的做事转变到了做正确的事情.
 
把自己当别人,把别人当自己,把别人当别人,把自己当自己
 
当你从解决问题后结果的喜悦中转变到对过程的沉思,你就变为了智者
 
井底之蛙不可怕,可怕的是五十步笑百步的人
 
教练比老师更可贵的是不仅仅教授理论,还要教授如何实践.所以好老师并不一定是好教练.
编辑 | 阅读全文(838) | 回复(0),人月&神话 发表于 2007-7-17 13:18
关键字:CMM
CMMI是一套过程成熟度的框架,也可以将CMMI理解为方法论,但不能将其理解为最佳实践.CMMI更多的是给出需要做什么,给出做一件事情的参考工具和方法,但究竟如何来做则组织完全可以采用自己的方法,也可以采用其他通过了CMMI企业在实施过程中的最佳实践.
 
通过了CMMI是否就说明过程一定有效?这个在CMMI的二级和三级是无法得到这个答案的.而在4-5级则开始对实际的组织能力效能进行度量.度量的指标有很多,但归到底都是成本和利润.软件是创造客户价值,但创造客户价值的最终目的都是为企业自身创造更多的价值财富.在初期企业为了获得一个通行证,为了过级而过级,这样过程改进带来的实际效果是微乎其微的.而且一般在过完级后管理者也不再重视,项目由于进度压力将CMMI好的东西全部抛弃掉,又回到老样子.企业实施CMMI唯一带来的就是一张证书.
 
做任何事情都要有目标,但实现目标的方法却千差万变,可以唯利视图,可以不择手段,可以不管过程,可以先学走再学爬.这些都可能实现预定义的目标.但我们考虑的不仅仅是实现一个简单目标,目标也是发展的要用长远的眼光来看待,考虑目标实现后对组织或项目后续的深远影响.因此重视过程而轻视目标不可取;但重视目标而忽略了过程同样造成严重和深远影响.这也是CMMI强调过程的一个重要原因.
 
建立通过过程改进提高成熟度,而实际的能够降低项目成本并赚取更大利润是CMMI实施的终级目标.任何子目标都必须围绕这这个来服务.在过2或3级的时候你可以讲先把过程或规则建立起来,暂时不考虑是否有效.但到了4,5级就必须考虑过程是否有效的问题.
 
让我们再来看下CMMI中不以效率为导向现象
1.明知无效的过程或过程中无用环节仍然在执行,沉默的大多数,极度危害的沉默
2.过程改进的建议不能够很好的采纳和实施,对无效过程沉默
3.局外人不站在项目和效益角度为了完成任务推……
编辑 | 阅读全文(2915) | 回复(3),人月&神话 发表于 2007-7-17 13:18

2007-7-17 13:18 | 同行评审基础和重点

同行评审的作用和好处
1.组织中最有才干的人没有参与项目也能够发挥作用(专家的评审可以跨项目)
2.另项目成员有一种认同感和参与感
3.一种自我学习,自我培训的自适应团队的形成
4.通过留意故障帮助预防故障
 
做不好同行评审的原因
1.进度驱动而不是质量驱动
2.评审人员是否是专家
3.评审的有效性无法很好的度量
4.没有遵循2/8原则注意评审的重点
5.评审时间被挤压,特别是工件的预审时间
 
都自主自发是否不需要评审
1.评审过程是一个团队学习过程
2.三人行必有我师
3.当局者迷,旁观者清
 
同行评审的基本概念(peer review)
由生产者的同行按照预定的规程对软件工作产品进行的评审,目的在于发现缺陷和需要改进之处。(CMM 1.1)
同行的概念在这里理解为参加评审的人员是不存在上下级关系的。
同行评审的作用在于尽可能早的消除软件工作产品中的缺陷

正式评审和非正式评审
评审是有成本的,因此适当采用非正式评审方式可以有效的加快评审效率和速度。尽可能早的发现问题。非正式评审不要建立正式的评审计划,评审意见记录方式也很灵活,一般适合3-4人内的小组面对面Review.
 
比较正式的小组评审过程(一种正式的评价技术,由不同于作者的一组人员详细检查软件需求、设计或代码,以发现错误、与开发标准的偏离和其它问题。)
 
评审前计划:参加人,要评审的工件,背景材料,检查单。主持是否仲裁?
概述和准备:预审前背景或目标介绍,预审
小组评审会议:主持人,讲解员,记录员必不可少。小组会议不仅仅是过预审意见,最好还需要对整个工件进行评审。评审要注意重点,如只重点评某几个业务功能。对于评审会议全部用来处理预审意见的评审结论为不通过。
……
编辑 | 阅读全文(1495) | 回复(1),人月&神话 发表于 2007-7-17 13:18
风险是一种不确定因素,对项目的四要素造成消极或积极的影响。不确定性是指依据现在的知识或数据无法确定事件发生的概率和事件发生造成的影响有多大。
风险基本属性(概率,后果,影响程度,影响时间区间和频率)
风险喜好者和风险厌恶者:对风险应对和项目计划都造成影响
 
风险容忍度:帮助项目团队对风险评级,简单说就是风险如果发生造成影响是否可接受
风险阀值:造成影响究竟多大就可接受,超过哪个值就不能接受而必须应对
 
风险管理计划
1.方法论,预算,风险类别,概率影响定义,干系人容忍度和汇报格式等都是计划重要输出
2.IT项目管理风险一般分为技术类,管理过程类和市场类。技术类涉及到产品需求,设计,测试,评审,编码等各个技术过程。管理类设计到项目管理,进度,成本,范围,沟通,人员等各方面的风险。
    
风险识别
1.注意项目范围说明书是一个重要输入
2.因为假设都可能是风险,假设分析和因果分析都是风险识别重要工具
3.风险识别要识别出引起风险根源
4.根源,风险清单,潜在应对和类别更新是风险识别输出
5.信息收集技术(头脑风暴,专家法,访谈,根源识别,SWOT)
6.组织级定义的风险检查单和历史的风险库可以帮助项目识别风险
 
定性风险分析
1.注意定性风险风险是一个主观的风险分析过程
2.主要分析发生概率和造成的后果(一般都用高,中,低表示即可),而且是针对每一个风险
3.范围说明,风险管理计划和风险登记册是重要输入
4.风险概率影响矩阵必须使用,确定风险的优先级和哪些风险需要应对
5.风险的数据质量评估和紧迫性评估
6.输出是按照类别分类,优先级排序的风险,同时确定哪些近期要应对,哪些继续观察
 
定量风……
编辑 | 阅读全文(1880) | 回复(1),人月&神话 发表于 2007-7-17 13:18

2007-7-17 13:18 | google重要二级域名整理

Google今天8岁了,特整理Google大事记和Google重要二级域名
 
 
1995年3月:谢尔盖-布林和拉里-佩奇在斯坦福大学春季聚会上首次见面。
1998年9月7日:组建Google公司,位于加州一个车库,有四名员工。募集了100万美元。当时布林和佩奇分别为24岁和25岁。
1999年2月到6月:Google得到风险投资基金的2500万美元注资。
2000年5月到6月:Google成为最大的互联网搜索引擎,雅虎选择Google作为默认的搜索结果供应商。
2001年3月到4月:埃里克-施密特加入Google担任董事会主席,很快被任命为CEO。
2002年9月到10月:Google在全球推出了关键词广告,提供关键词广告服务。
2004年3月31日:Google宣布了免费电子邮件服务Gmail。
2004年4月29日:Google向美国证券交易委员会提交IPO申请文件。
2004年7月12日:Google表示将在纳斯达克挂牌交易,并披露股票代码.
 
 
编辑 | 阅读全文(1913) | 回复(0),人月&神话 发表于 2007-7-17 13:18
离惠州2005年60km罗浮山徒步已经快一周年了,相信对每一个参加的人来讲都是一次难忘的经历。科协05年一共组织了三只队伍参加,虽谈不上声势浩大,但规模也不算小了。而且还有快10个人的后勤团。
 
印象里应该是周六下午包车从深圳出发开往惠州,晚上扎营在半山腰,偶和夜雪混帐,睡袋是不告诉你MM帮偶借的,晚上在山下吃完饭再扎好帐篷就快点了,中间冰笛给大家表演了葫芦丝,小羊给大家唱了儿歌。当晚半山腰的停车场一大片空地基本全部被帐篷覆盖了,估计应该有200-300人,第一次睡帐篷一直睡不着,到了12点鼾声此起彼伏,大珠小珠落玉盘,后来看了下时间基本2,3点才入睡,到了清晨4点半,基本就起来了,感谢旁边农家给我们煮的粥,喝了点粥再吃个咸蛋就准备上路了。
 
由于有一半的山路,水基本上就带了3-4公升,再加上些干粮背包至少有10斤左右吧。清楚山上的空气是异常的新鲜,大家的精神也都很好,虽然我们签到的比较晚,但很快就赶到前面去了。
 
 
下到山门口,天才基本亮了,把头灯收好继续赶路,罗浮山风景确实不错
 
 
走了7-8KM后开始爬山,山不是特别陡,但由于背了东西爬起来还是比较吃力。我走平地还可以但一遇到山路就不行了,幸好有拐杖帮自己省了不少力气。到第一个签到点是12-13……
编辑 | 阅读全文(1082) | 回复(0),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 国旗、国徽和国歌

 
中华人民共和国国旗是五星红旗。国旗旗面的红色象征革命;五角星用黄色是为了在红地上显出光明。大五角星代表中国共产党,四颗小五角星代表中国人民;五颗五角星相互的关系,象征中国共产党领导下的人民大团结。

中华人民共和国国徽,中间是五星照耀下的天安门,周围是谷穗和齿轮。麦稻穗、五星、天安门、齿轮为金色,圆环内的底子及垂绶为红色,金、红两种颜色在中国是象征吉祥喜庆的传统色彩。天安门象征中国人民反帝反封建的不屈的民族精神;齿轮和谷穗象征工人阶级与农民阶级;五颗星代表中国共产党领导下的人民大团结。中华人民共和国国歌由诗人田汉所作、音乐家聂耳作曲,创作于1935年。“起来!不愿做奴隶的人们!把我们的血肉,筑成我们新的长城!中华民族到了最危险的时候,每个人被迫着发出最后的吼声。起来! 起来! 起来!我们万众一心,冒着敌人的炮火前进!冒着敌人的炮火前进!前进! 前进! 进!”这首歌原名《义勇军进行曲》,是电影《风云儿女》的主题歌。影片描写的是30年代日本侵略中国东北时,中华民族处于生死存亡的紧急关头,人们勇敢地走向抗日前线的故事。
《义勇军进行曲》高昂激越、铿锵有力,表达了中国人民为争取民族解放事业不惜抛头颅、洒热血的决心,体现了中华民族勇敢、坚强、团结御侮的优良传统。正因为如此,1949年9月27日中国人民政治协商会议决定此歌为中华人民共和国代国歌;198……
编辑 | 阅读全文(1320) | 回复(0),人月&神话 发表于 2007-7-17 13:17

2007-7-17 13:17 | 积极的心态-整理

古时候有个佛学造诣很深的人,听说某个寺庙里有个德高望重的老禅师,便去拜访。老禅师的徒弟接待他时,他态度傲慢,心想:我是个佛学造诣很深的人,你算老几?

后来老禅师十分恭敬的接待了他,并为他沏茶。可在倒水时,明明杯子已经满了,禅师还在不停地倒。他不解地问:“大师,为什么杯子已经满了,还要往里面到?”

大师说:“是啊,既然已满了,干嘛还倒呢?”
 
有企业花钱培训员工,有的员工学到了东西,而有的员工则抱怨没的学。其实,有的学没的学,关键在于自己想不想学,有没有“空杯心态” 。

在职场上真正经得起风雨的人,是那些有真才实学的人,有“空杯心态”的人。

故事1:
当老婆刚刚冲完澡出来老公正要开始淋浴时门铃响.在几秒争吵谁该去开门之后老婆放弃了,裹了条毛巾急忙下去开门.她打开门看见Bob他的邻居,在她还没开口之前Bob就说“如果你把那条毛巾拿下我就给你$800”老婆想了想,就脱下毛巾赤裸站在Bob面前,过了几秒Bob给了钱就走了,老婆困惑又兴奋她的好运裹上毛巾上楼,当她回到浴室老公问她“刚刚是谁呀”“隔壁的Bob啦”她回答“很好”老公说“那他有没有拿他欠我的$800还我吗?"!
 
寓意:在未了解事情的真相之前,永远不要轻易自行判断而造成错误,而且还不知道自己有多难堪。
 
故事2:
有个牧师开车在路上见到路旁有个修女,便停车主动载她一程她进车后便翘起脚來,让她可愛的美腿从长袍中露了出來牧师看了一眼高兴的差点让车子出了意外在控制车子后,他偷偷摸摸的将他的手往美腿上移动.修女看了看他便说"神父,记得圣经129吗?"
 
神父脸红连忙道歉,他被迫移开他的手但是他的视线却离不开他的美腿.在几次换档之后,他的手又再次滑向美腿.修女又说“神父,记得圣经129吗?”神父又在一次道歉“对不起”……
编辑 | 阅读全文(1089) | 回复(0),人月&神话 发表于 2007-7-17 13:17
 
较之于过程和工具,应更注重人及其交互的价值
 
较之面面俱到文档,应更注重可运行软件的价值
 
较之合同谈判,应更注重跟客户合作的价值
 
较之遵循计划,应更注重响应需求变化的价值
 
根据此宣言得到如下支持原则:
 
1.我们得最高优先级是通过尽早和经常交付有价值得软件令客户满意
2.不断得交付软件,以每两周或两个月为周期
3.可运行软件是工作进展得主要度量标准
4.以积极得态度对待需求得变化,即使在开发末期也不例外
5.业务人员和开发人员最好能够一起工作
6.在开发团队中,面对面交谈始终是最有效率和效果得交流方式
7.最好得系统架构,需求和设计文档产生于自组织的团队
8.简单化,实用是至关重要的
9.团队应该定期对运作方法进行改进和反思
 
 
编辑 | 阅读全文(1134) | 回复(0),人月&神话 发表于 2007-7-17 13:17
(共 973 条) 1 2 ... 35 36 37 38 39 ... 64 65 翻页至

仅列出标题