导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
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
  • 访问:960903
  •  
Product
28: Requirements gold-plating(需求镀金). Some projects have more requirements than they need, right from the beginning.
只做该做的事情,一个也不能少,一个也不能多。
在把时间浪费在界面的花哨上面的时候,可能却忽略了一些重要的非功能需求的实现。

29: Feature creep. Even if you're successful at avoiding requirements gold-plating, the average project experiences about a 25-percent change in requirements over its lifetime (Jones 1994).
有效的控制需求变更对快速软件开发至关重要。必须形成相关的规程。
30: Developer gold-plating. Developers are fascinated by new technology and are sometimes anxious to try out new features of their language or environment or to create their own implementation of a slick feature they saw in another product
对项目来说风险最小,最可控的就是采用稳定成熟的技术。而开发人员中经常有对新技术极端狂热份子,喜欢在项目中应用和试验新技术。
新技术研究可以单独设立预研项目,而不应该正式的项目中采用。
31: Push-me, pull-me negotiation.
32: Res……
编辑 | 阅读全文(1122) | 回复(0),人月&神话 发表于 2007-7-17 13:19
14: Overly optimistic schedules. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hurts long-term developer morale and productivity.
乐观进度表现的方面有:1)对项目的相关风险考虑不足,没有相关的风险管理计划和对风险应对的处理时间。2)项目没有预备一定的缓冲时间。3)项目裁剪或省略掉了生命周期中重要的过程或阶段,如需求分析,设计,或相关评审。
乐观进度是项目成员承担过多的压力,从长期来看伤害团队士气和生产率。
15: Insufficient risk management. if you don't actively manage risks, only one thing has to go wrong to change your project from a rapid-development project to a slow-development one.
如果不积极的分析和应对风险,快速开发是一句空话。
16: Contractor failure. Risks such as unstable requirements or ill-def……
编辑 | 阅读全文(1072) | 回复(0),人月&神话 发表于 2007-7-17 13:19
英文内容摘录自《快速软件开发》一书的第四章。
1.Undermined motivation:Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor
团队激情始终都是第一位的要素,启动会议,物质和精神激励,聚会,假期,有张有弛,团队建设和团队精神都是提升团队激情的方法和手段。
2.Weak personnel:After motivation, either the individual capabilities of the team members or their relationship as a team probably has the greatest in-fluency on productive
人员的流动和不稳定是对软件开发质量和生产率的又一个重要因素。如果我们时时都在做或雇佣从新手逐步培养为熟手的过程,但我们的生产率始终不可能达到一个较高的水平。可以参考《最后期限》中的生产率模型描述。
所以在挑选和雇佣人员的时候,请优先考虑谁能够更稳定,持久的工作;而不是谁在项目中能够做更多的工作。
3.Uncontrolled problem employees. Failure to deal with problem personnel also threatens development speed. This is a common problem and has effective teams.
问题员工带来的负面影响绝对不仅仅是个人,而是影响到整个团队的激情和生产率。
4: Heroics. Some software developer……
编辑 | 阅读全文(973) | 回复(0),人月&神话 发表于 2007-7-17 13:19
摘抄自《OOD 启思录》--Arthur J.Riel 著 鲍志云 译  
 
“你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃,若违背了其中的一条,那么警铃就会响起。”
----------Arthur J.Riel

(1)所有数据都应该隐藏在所在的类的内部。p13
(2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者。p15
(3)尽量减少类的协议中的消息。p16
(4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17
如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17
(7)类之间应该零耦合,或者只有导出耦合关系。也即,一个类要么同另一个类毫无关系,要么只使用另一个类的公有接口中的操作。 p18
(8)类应该只表示一个关键抽象。p19
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响,则将对包中的所有类产生影响,而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。p19
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即:互不沟通的行为)。p19
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类,而不只是对象扮演的角色。p23
(12)在水平方向上尽可能统一地分布系统功能,也即:按照设计,顶层类应当统一地共享工……
编辑 | 阅读全文(873) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 读怀恩师后的破碎记忆

怀恩师是德鲁克回忆录《旁观者》中的一篇文章,读了《卓有成效的管理者》后我基本没有留下太多的印象,这可能也是我谈到过的这类管理或情商类的书籍往往是必须有多年相关的经验和亲身经历后才能够真正读懂吧。而对于《旁观者》,刚读了几个章节后已经可以吸引我读下去了,正如推荐序里面说到的一样:畅销书不一定是好书,而好书不一定畅销。
 
德鲁克是幸运的,因为在小学时候就遇到了两位恩师,而我们大部分人可能一辈子都遇不到一位恩师。好老师和恩师应该是有区别的,老师的课讲授的很好,治学严谨,可能就是一位值得尊敬的好老师了;而对某人来说算得上恩师的更多的是较会你学习和思维的方法,对你的价值观,人生观,个人习惯造成重大的影响的人。师者,传道授业解惑者,足可见作为老师传道是多么的重要。
 
这里有必要先摘录书里面的一段文字:
 
[p75]:因此,有两种截然不同的老师:一种是天赋型的,另一种则为学生设计学习课程,以方法为主。教书是一种天赋才能,天生的老师可以自我改进并成为更好的老师;以方法为主的老师则有一套几乎人人适用的学习法。事实上,天生的老师再运用一点教学法就可以成为伟大的老师,也可以成为无所不能的名师。
 
苏格拉底实际上也是一个利用教学法,引导学生学习的人。苏格拉底的方法并不是教的方法,而是学的方式,一种特别设计的学习法。他认为教师教的不是学科,而是学习方法,学生从而学到该学科的知识。学是有成果的,而教是虚假的,这种看法使她成为阿波罗神话中"希腊最有智慧的人"。
 
教书是一种天赋,学习则是一种技巧。我们发现,学习是深植于人们身上的,人类以及所有的生物都是按照一定的方法学习的"学习体"。
 
[p77]:对真正的老师而言,没有所谓的坏学生,苯学生,或者是懒学生之别,只有好老师和坏老师之分。
 
……
编辑 | 阅读全文(1402) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | CMMI培训总结报告-转载

 
1、 二三级的区别
就阶段上来讲,三级抽取了二级每个项目的公共要求è标准的过程定义+裁减指南
二级中项目的过程定义取决于改项目,三级则是由EPG来具体提供建议。EPG团队中专长工程过程和组织级过程的人负责自己那块的裁剪偏差。
三级才有OPF,因为二级后总结出了有权威的人去负责,这些并不是高层能替代的。也就是说二级没有必要有EPG。
 
重点是标准过程定义,通过对多个项目分析和研究形成组织级过程,告诉你这个过程可以很好指导你的项目成功,而不是需要每个项目都去发明创造。
 
2、 连续式和阶段式浅辨
成熟度等级给组织提供了一个改进方向,这点上stage比continues更有优势。特别是组织自己也不明确改进方向,如不知道先做什么,后做什么的情况下
continues可以一个PA一个PA的去做,而staged则不可以,是一些固定设置的组合
两者的评估结果都能达到组织的商业目标
对某个过程域,提供的内容基本一致,只不过实现的方式不一样
连续式有6个等级,从CL0到CL5,而阶段是只有一个è因为阶段式是看不到能力等级的,阶段式只有ML1~5
 
连续型关注单一过程的能力,如可以说自己RD需求开发很强,阶段型关注组织级成熟度,是综合实力,要多个KPA都很强才能达到要求。
 
3、 SG和GG
SG不是能力——要做什么事,不是能力
GG才是能力——做了什么事,如何做才是能力
GG1è能力1,GG2è能力2
也就是说:“我做成了这件事,这并不代表我有能力;我每次总能做成这样的事,这才代表我很有能力”。
&nbs……
编辑 | 阅读全文(2850) | 回复(0),人月&神话 发表于 2007-7-17 13:19
推荐的相关网站有(在这几个地方可以找到比较多的源代码或开源项目供学习)
http://www.windowsforms.net/
http://www.asp.net/
http://sourceforge.net/index.php (开源项目站点)
http://www.codeproject.com/
http://www.cnblogs.com/ (博客园)
http://blog.joycode.com/ (博客堂)
 
这里推荐学习的范例项目主要有:
 
 
 
微软智能客户端应用TaskVision或IssueVison的学习。
http://www.windowsforms.net/Default.aspx?tabindex=4&tabid=49
 
微软的BS应用的学习asp.net forum……
编辑 | 阅读全文(1623) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | DotNet开发基础知识学习

这里更多的没有给具体的学习方法和如何学,更多的是给出了学后大概要达到的一些效果。具体的学习思路可以参考微软网站或博客园等相关的专题知识。
 
学习更多的是学习方法问题,所以善于充分利用他人的资源,前人研究成果,充分利用网络资源,可以加快上手速度,但基础的知识仍需要上手后完整的进行学习和回顾。
 
这些学习步骤和内容一是参考我原来的一些学习方法进行改进,另外是现在新员工进项目的一些学习步骤。项目培养新员工一般采用的是做一个跟项目架构很类似的一个实际练习和作业,这里能够明显看出的就是原来有相关基础的新员工练习可以很快完成,而原来基础知识较缺乏的很难短时间完成练习。
 
第一周:熟悉IDE,环境,工具和常见应用模式
第一周的目的是熟悉开发工具和环境,常见的开发方式和模式,解决方案和分层,基本不涉及任何复杂内容。
这里可以参考微软提供的快速入门网站:http://chs.gotdotnet.com/quickstart/default.aspx
 
题目1:输入一个人的姓名信息,如果是英文名返回Hello,+输入的名称。如果是中文名返回你好,+输入名称
 
需要完成的内容:
1.实现该应用为一个Console App的应用。
2.实现该应用为一个Web App的应用,Win App的应用,不考虑分层
3.建立一个解决方案,包括WinUI和WebUI两个UI层项目,包括一个BusinessRule的逻辑层项目。将业务逻辑的实现独立到逻辑层项目中来完成。
4.解决方案再增加一个DataAccess的项目,自己建立一个数据库,选择Oracle或Sql Server都可以,学习最简单的ADO.Net相关方法的使用。增加业务逻辑为:如果输入的姓名信息在DB的Users中找不到,要提示用……
编辑 | 阅读全文(1608) | 回复(0),人月&神话 发表于 2007-7-17 13:19
国内现在的快速开发平台很多,但完全遵循MDA思路的还暂时没有。更多的是从数据库逆向的思路进行了,整个分析和设计过程是没有融入到平台工具中的。
 
金富瑞:UCML快速开发平台 http://www.ucml.com.cn/
简评:仍然是后天数据库逆向驱动思路,工作流功能不够强大。
 
思维加速:协同软件 http://www.justep.com/
简评:思路和理念完善,产品较成熟
 
普元EOS:面向构件的中间件
简评:面向构件中间件平台,有良好的体系结构保证,融入部分需求分析,建模和MDA思路。
 
世雄EMP:http://www.centuryemp.com/emp.htm
西安协同:http://www.synsoft.com.cn/
点击科技:http://www.goto2008.com/index.htm
 
编辑 | 阅读全文(2117) | 回复(1),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 沉思的实践者

持续学习要求开发者不断提高自身的技能。
 
软件工程思想的一个核心问题是:程序员被严重误导,以为自己只需要了解某一个主题的知识就够了。可是,软件开发并非如此,这个领域在飞快的发展和变化。
 
计算机硬件的速度在不断的提升,价格在不断的下降,许多从前的经验已经不再适用。跟上技术潮流的能力日益变得重要,那些能够意识到技术变革的发生、并能够及时运用新技术创建应用程序的开发者成为了优秀的开发者。
 
只有软件工匠不断的学习,不断地将软件开发技艺的边界向前推进,软件开发技术才能够不断的发展。
 
-摘录自《软件工艺》一书末。
编辑 | 阅读全文(977) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 安得罗语录

周末在看《暗算》,确实是一部反间谍和密码的好片。其中的安得罗语录更是比较经典和值得回味,特搜索到摘录出来:
 
就像我们两国的关系已经没机会回到从前一样,我们也没机会做师生了。 
 
当今世上,冯"诺伊曼博士是最深不可测的破译家,他有两个脑袋,一个是东方的,一个是西方的。他收罗了大批亚洲学子,为的是领略吊诡的东方智慧…… 
 
神说,年轻人额头破了是开天窗的好事,就象喜鹊叫,说明有喜事降临。 
 
破译技术作为一门数学科学,尖锐而深邃的数学能力,跟良好的心理素质,是一样必要又重要的,两者犹如一对飞翔的翅膀,缺一不可。 
 
密码是反科学、反人性的。说到底,密码玩的是欺骗,是躲藏,是暗算。兵不厌诈,密码是兵器,是兵器中的暗器,是人间最大的狡诈。哈哈哈,研制和破译密码的人都是撒旦! 
 
我们俄国有句谚语,爱情不是蜜,但它能粘住一切。 
 
分析师和破译师的关系,就像文字和文章的关系,你要写文章,首先必须认识足够的文字。
 
分析师是教字的,破译师是识字的…… 
 
安,你知道俄罗斯有句谚语,那就是“惟有爱与恐惧是不能掩饰的。” 
 
爱情,哦,可怕的爱情,一旦坠入红尘,那将万劫不复。 
 
谁记得一切,谁就感到沉重。这句话适合男人和女人之间,也适合国家和国家之间。 
 
它也可能出现牵一动百的多米诺现象,从而导致整部的密码崩溃。 
 
小伙子,你可能破译一千条密码,却未必会解决一个爱情问题。幸福的家庭都是相似的,不幸的家庭却各有各的不幸。……
编辑 | 阅读全文(1271) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 关于最佳实践

最佳实践是和方法论密不可分的两个概念。最佳实践是基于某个特定的方法或方法论,然后根据特定的条件和场景去应用方法论而取得了成功的案例。
 
英文中关于最佳实践的定义为:
1. A technique or methodology that, through experience and research, has proven to reliably lead to a desired result.
 
通过实践和研究已经被证明了可以导致成功的技术和方法。
 
2. The winning strategies, approaches, and processes that produce superior performance in an organization.  A best practice is a by-product of a successful end-result.
 
在组织中可以产生很好绩效的可赢的战略,方式和过程。一个最佳实践就是一个成功结果的产出。
 
最佳实践和方法论是很难讲清楚谁先谁后的问题。方法论本身就是通过无数次的实践总结出来的一套可行的理论和过程。而最佳实践又是基于某个方法论的成功应用。所以说两者间更多是相辅相成的关系。
 
你应用最佳实践取得成功是基于诸多假设,条件和场景下的。而这些特定的场景和条件其它项目或个人并不一定具备,所以你得出的最佳实践并不一定适合他人。所以不应该盲目的去推崇和照搬别人的最佳实践,我们学习最佳实践更多的是应该去学习别人应用最佳实践的方式和思维,而不是完全按照别人实践路子来规划自己的成功。
 
一个完善和成熟的方法论可以产生出N个多条路径的最佳实践,其产生的关键也在于是否真正理……
编辑 | 阅读全文(1149) | 回复(0),人月&神话 发表于 2007-7-17 13:19
--红色部分为我添加的一些内容
1. 开发流程(Development process)-为手头的项目选择适当的开发生命周期流程很重要(CMMI三级自定义过程最大的一个裁剪项),因为其他的所有活动都是从这个流程派生出来的。现代的软件开发项目多数都是在瀑布式流程的基础上采用某种螺旋式方法。有几种方法可供选择,包括 Rational 统一流程(Rational Unified Process,RUP)、IBM? Global Services 方法(IBM? Global Services Method)以及极端编程(eXtreme Programming,XP)。(还要改进型的瀑布模型,增量等相关模型可以供选择)流程当然比根本没有要好,但在多数情况下流程的执行情况要比使用的是什么流程更重要。以上列举的常用方法都包含关于如何执行流程的指南和构件模板。此外,RUP 还有一系列描述使用 RUP 的最佳实践的书  [1][2][3][4],即便不选用 RUP,这些书也是获得最佳实践的极好来源。给 RUP 加插件也是可以的。请为基于 WebSphere? J2EE 的项目下载  WebSphere 插件。(RUP是很好的一套增量迭代的开发方法,RUP方法论可以更好的应当变化和体现架构设计在开发过程中的主导作用,但真正用好并不容易)

2.需求-收集需求就需求达成一致是项目成功的基础。这并不一定意味着需要在建立好体系结构、完成设计和编码工作之前确定所有的需求,但对于开发小组来说明白需要构建什么是很重要的。质量需求分两种:功能性的和非功能性的。一种记录功能性需求的好方法是使用用例(Use Case)。注意:用例被用于非面向对象的项目。Armour 和 Miller 著有一本关于用例主题的权威著作 [5]非功能性需求描……
编辑 | 阅读全文(1066) | 回复(0),人月&神话 发表于 2007-7-17 13:19
培训是构建一个有战斗力和学习型团队必不可少的内容。在CMMI的三级专门有OT组织级培训过程域,另外还有很多GG公共实践都跟培训有关系。培训在PMP中属于人力资源计划的一部分内容,因此同样的包含了计划,执行,监控,总结等各个方面的内容。
 
1.培训需求的获取
 
培训需求收集表:让团队成员自己选择所喜欢的课程是培训需求收集的一个重要手段,团队中的每个人应该是比较清楚自己知识的掌握情况和相关技能匮乏情况的,他们会主动去选择不熟悉和感兴趣的培训课程。在需求收集前项目最好首先列出可能进行的各种技术,工具和技能的培训清单,每位成员可以在清单中选择自己最感兴趣的3-4门课程,这样信息在收集回来汇总后就可以排出培训课程安排的优先级别了。
 
项目成员技能评估:对项目成员进行技能的评估,技能的评估可能根据平时项目成员工作的情况,对工件的Review的情况,与项目成员的单独沟通,团队技能练习等多种方式收集团队成员的技能情况。然后通过专家法对项目成员的技能做大致评估,当发现大多数成员都存在技能欠缺的点时候就可以考虑安排专门的培训。
 
项目的里程碑总结和复盘:这是项目的培训的一个重要来源,通过项目阶段的总结来发现项目出现的问题,如上个版本的项目在集成测试阶段花费了大量时间导致项目进度延误后就要分析可能的原因:如果是项目架构设计的接口定义不清晰导致的就需要对架构进行专门培训,如果是项目成员单元测试质量差引起的就需要专门对开发人员进行测试基础知识和单元测试的培训。项目存在问题如果不考虑态度问题的话根源将都是成员本身技能欠缺,本身技能欠缺的解决方法则只有靠自我的学习和培训。
 
2.安排培训计划
 
对于培训的时间的安排要考虑各次培训的时间间隔,培训安排的太多反而影响到成员对培训内容的消化和理解……
编辑 | 阅读全文(1235) | 回复(0),人月&神话 发表于 2007-7-17 13:19
工作流参考模型
工作流参考模型由国际"工作流管理联盟WfMC"给出,它定义了工作流管理系统的一些标准规范,工作流管理工具的应用编程接口,使工作流应用间可以更好的集成和交互。
 
参考模型中提供了五类接口,有关过程模型的定义则构成了接口一的核心内容。接口一早期的标准为WPDL(Workflow Process Definition Language),后来,这一接口的规范变更为XPDL。XPDL是至今工作流领域最为重要的一个标准,目前大多数工作流引擎是依据该标准设计开发的。
 
工作流的中的三类数据:
1.工作流控制数据(Workflow Control Data):工作流引擎通过控制数据来辨别每个过程或活动实例的状态。这些数据决定了工作流具体的流程处理逻辑,任务分派和流转逻辑。因此在工作流建模中定义的关于工作流,任务,分支和连接弧,转变规则和条件,权限,角色和参与人等信息都是工作流的控制数据。
2.工作流相关数据(Workflow Relevant Data):这块实际指工作流的实例数据,这是根据实现定义的工作流模型产生出来的实例数据,包括工作流实例,任务实例,活动实例,连接弧实例等。
3.工作流应用数据:这里指业务对象的实例数据,如订单对象,合同对象的实例数据。业务对象的实例数据部分也是工作流的控制数据,需要控制到工作流流程的转换。
 
工作流的建模
工作流模型描述了一个工作流应用在执行阶段所需要的所有参数信息和控制信息。这些规则包括了过程的开始和完成条件,构成过程的活动以及活动间的转变规则,用户所需要完成的任务,……
编辑 | 阅读全文(1231) | 回复(0),人月&神话 发表于 2007-7-17 13:19
(共 973 条) 1 2 ... 24 25 26 27 28 ... 64 65 翻页至

仅列出标题