?!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1、性能仅仅是很多设计因素之一
x软g设计中的一个重要因?-性能Q这好象也是用户最兛_的事情。一个性能不佳的Y件将不可避免被重写?/span>
但是你的设计q必d有可靠性,可用性,便携性和可扩展性。你应该在工E开始就应该定义q区分好q些因素Q以便在工作中恰当用。性能可以是,也可以不是优先最高的因素Q我的观ҎQ给每个设计因素应有的考虑?/span>
2、不要低估对软g规模的需?/span>
Internet 带给我们的最大的教训是你必须在Y件开发的最初阶D就考虑软g规模的可扩充性。今天只?00人的部门使用的应用程序,明天可能会被有好几万人的l织使用Q下月,通过因特|可能会有几百万Z用它?/span>
在Y件设计的初期Q根据在用例模型中定义的必须支持的基本事务处理,定软g的基本功能。然后,在徏造系l的时候再逐步加入比较常用的功能。在设计的开始考虑软g的规模需求,避免在用LH然增大的情况下Q重写Y件?/span>
3、管理接?/span>
你应该在开发阶D늚早期定义Y件模块之间的接口。这有助于你的开发h员全面理解Y件的设计l构q取得一致意见,让各模块开发小l相对独立的工作。一旦模块的接口定之后Q模块怎样实现׃是很重要了。从Ҏ上说Q如果你不能够定义你的模块“从外部看上M是什么样子”,你肯定也不清楚模块内要实C么?/span>
4、走q\需要更长的旉
在Y件开发中没有捷径可以走。羃短你的在需求分析上q旉Q结果只能是开发出来的软g不能满用户的需求,必须被重写。在软g建模上每节省一周,在将来的~码阶段可能会多花几周时_因ؓ你在全面思考之前就动手写程序。你Z节省一天的试旉而漏掉了一个bugQ在来的维护阶D,可能需要花几周甚至几个月的旉M复。与其如此,q不如重新安排一下项目计划。避免走捷径Q只做一ơ但要做寏V?/span>
5、不要信赖Q何h
产品和服务销售公怸是你的朋友,你的大部分员工和高层理人员也不是。大部分产品供应商希望把你牢牢绑在他们的产品上,可能是操作系l,数据库或者某个开发工兗?/span>
大部分的N和承包商只关心你的钱q不是你的工E。大部分E序员认Z们自己比其他人更优秀Q他们可能抛弃你设计的模型而用自己认ؓ更好的。只有良好的沟通才能解册些问题。要明确的是Q不要只依靠一家品或服务提供商,即你的公司Q或l织Q已l在建模、文档和q程{方面向那个公司投入了很多钱?/span>
6、证明你的设计在实践中可?/span>
在设计的时候应当先建立一个技术原型, 或者称为“端到端”原型。以证明你的设计是能够工作的。你应该在开发工作的早期做这些事情,因ؓQ如果Y件的设计Ҏ是不可行的,在编码实现阶D|论采取什么措施都于事无补。技术原型将证明你的设计的可行性,从而,你的设计更Ҏ获得支持?/span>
7、教育你的听?/span>
你花了很大力气徏立一个很成熟的系l模型,而你的听众却不能理解它们Q甚xp-qؓ什么要先徏立模型都不知道。那么你的工作是毫无意义的?/span>
教给你开发h员基本的建模知识Q否则,他们会只看看你画的漂亮图表,然后l箋~写不规范的E序。另外, 你还需要告诉你的用户一些需求徏模的基础知识。给他们解释你的用例和用L面模型,以他们能够明白你要表达Cѝ当每个人都能用一个通用的设计语a的时候,你的团队才能实现真正的合作?/span>
8、应用已知的模式
目前Q我们有大量现成的分析和设计模式以及问题的解x案可以用。一般来_好的模型设计和开发h员,都会避免重新设计已经成熟的ƈ被广泛应用的东西?nbsp;
9、研I每个模型的长处和弱?/span>
目前有很多种cȝ模型可以使用,用例捕获的是pȝ行ؓ需求,数据模型则描q支持一个系l运行所需要的数据构成。你可能会试囑֜用例中加 入实际数据描qͼ但是Q这对开发者不是非常有用。同P数据模型ҎqY仉求来说是无用的。每个模型在你徏模过E中有其相应的位|,但是Q你需要明白在什么地方,什么时候用它们?/span>
10、在现有d中应用多个模?/span>
当你攉需求的时候,考虑使用用例模型Q用L面模型和领域U的cL型。你设计软g的时候,应该考虑制作cL型,序图、状态图、协作图和最l的软g实际物理模型?/span>
E序设计人员应该慢慢意识刎ͼ仅仅使用一个模型而实现的软g要么不能够很好地满用户的需求,要么很难扩展?/span>
11、带工具的傻瓜还是傻?/span>
你给我CAD/CAM工具Q请我设计一座桥。但是,如果那桥徏成的话,我肯定不惛_W一个从桥上q的人,因ؓ我对建筑一H不通。用一个很优秀的CASE工具q不能你成Z个徏模专Ӟ只能使你成ؓ一个优UCASE工具的用者。成Z个优U的徏模专安要多q的U篏Q不 会是一周针Ҏ个h值几千美元工L培训。一个优U的CASE工具是很重要Q但你必d习用它Qƈ能够使用它设计它支持的模型?/span>
12、理解完整的q程
好的设计人员应该理解整个软gq程Q尽他们可能不是精通全部实现细节。开发是一个很复杂的过E,除了~程、徏模、测试等你擅长工作外Q还有很多工作要做。好的设计者需要考虑全局。必M长远考虑如何使Y件满用户需要,如何提供l护和技术支持等?/span>
13、技术会变,基本原理不会
如果有h说“用某U开发语a、某个工h某某技术,我们׃需要再做需求分析,建模Q编码或试”。不要相信,q只说明他还~Zl验。抛开技术和 人的因素Q实际上软g开发的基本原理?0世纪70q代以来没有改变过。你必须q定义需求,建模Q编码,试Q配|,面对风险Q发布品,理工作人员 {等。Y件徏模技术是需要多q的实际工作才能完全掌握的。好在你可以从我的徏议开始,完善你们自己的Y件开发经验?/span>
14、常做测试,早做试
如果试对你的Y件来说是无所谓的Q那么你的Y件多半也没什么必要被开发出来。徏立一个技术原型供技术评审用,以检验你的Y件模型。在软g生命周期中,晚发现的错误越难修改,修改成本昂c尽可能早的做测试是很值得的?/span>
15、把你的工作归档
不值得归档的工作往往也不值得做。归档你的设惻I以及Ҏ设想做出的决定;归档软g模型中很重要但不很明昄部分?nbsp;l每个模型一些概要描qC使别人很快明白模型所表达的内宏V?/span>