![](https://img-blog.csdnimg.cn/20201014180756925.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
软件工程
dahuzizyd
这个作者很懒,什么都没留下…
展开
-
敏捷软件开发主要包括哪些方法
敏捷软件开发主要包括哪些方法: AD - Agile Database Techniques AM - Agile Modeling ASD - Adaptive Software Development Crystal FDD - Feature Driven Development DSDM - Dynamic Systems Development Method Lean Software原创 2004-07-21 09:53:00 · 1199 阅读 · 1 评论 -
《敏捷建模》读后感
这本书买了有一段时间了,可是最近才算真正过了一遍,书不算厚,300页左右,但是看完后感觉收获颇多。这本书并没有教给你具体的建模技术,比如UML,模式等的使用,或者手把手的教你一个例子,而是首先提出敏捷建模的原则,实践来解释什么是敏捷建模和其关键部分。然后展开说明敏捷建模中各制品,和统一过程,XP的结合等。对于我自己来说读这本书最大的收获不是获得了某些技术,而是明白了一个道理,在软件开发过程中,对“原创 2004-09-10 13:17:00 · 1358 阅读 · 2 评论 -
文档,又是文档
文档,又是文档,《敏捷建模》中关于文档的一段文字,觉得非常好。害怕失去所有的人而导致过度的文档很多组织机构害怕失去他们的软件开发团队,因为一旦团队全部或大部分的人离开,非常重要而且常常没有几率的知识会和他们一起离开。常见的失去团队的原因有:有竞争者从你那里掘走了团队,以便启动他们自己的项目有的开发人员习惯性的跳来跳去,从不在任何公司久留。在团队刚刚完成项目之后你有意解散了他们。为了原创 2004-08-27 16:06:00 · 2293 阅读 · 3 评论 -
对项目目标的一点想法
公司已经有一个比较成熟的产品了,而且销售情况也不错。现在作的项目是该产品的后续产品,但是并不是简单的升级,如果仅仅是用.net来把以前的VB作的东西来实现一遍,就没有什么实际的意义了。由于要和先前的产品相比有质的飞跃,所以从结构和业务上几乎都是重新设计,但是由于新的架构的实现难度比较大,造成现有的人力和技术实力无法完成具体的实现。形成了一种高不成,低不就的情况,一方面,目标太高,达不到,另一方面,原创 2004-08-25 15:57:00 · 1082 阅读 · 1 评论 -
读《敏捷建模》时看到的一段文字,深有感触,摘抄下来
在书中270页有权力的催着要纸的人??????? 在比较大型的的组织机构里,这样的IT专家是很普遍的:他们已经有好几年的时间没有直接参与国软件开发了-编程、建模、测试或管理。这些人通常担任基础设施服务的角色,例如软件过程管理,复用管理或者程序管理,并且经过了一段时间他们的角色已经退化到了这样的地步:他们工作的中心就是“催纸”。这些人通常要求个人或团队提供进度报告,由他们进行检查并提供反馈;举行进度原创 2004-08-23 18:48:00 · 1237 阅读 · 0 评论 -
项目管理者的尴尬
近来项目基本处于停顿状态,所以有时间停下来好好总结下。由于项目进行中经历了项目经理的更换,所以对不同的管理方法有一些自己的看法。试着从程序员的角度来看看项目管理。先看两个问题:1.文档很多程序员都有一样的想法,就是很讨厌写文档(起码是过多的文档),可是项目管理者偏偏最看重这个,他们整天催你交他认为必须的文档,拿到手后又这也不对,那也不对,吹毛求疵。程序员讨厌这样,但是却不能表现出什么不满,原创 2004-08-16 11:03:00 · 1428 阅读 · 6 评论 -
敏捷软件开发宣言
引自邓辉译《敏捷软件开发-原则、模式与实践》敏捷软件开发宣言 我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,我们认为: 个体和交互????????? ? 胜过 过程和工具可以工作的软件??? 胜过 面面俱到的文档客户合作?????????????? 胜过 合同谈判响应变化?????????????? 胜过 遵循计划 虽然右项也具有价值,但我们认为左项具有更大的价值。原创 2004-07-21 12:56:00 · 1077 阅读 · 0 评论 -
敏捷开发的原则
Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. Welcome changing requirem原创 2004-07-21 10:20:00 · 1002 阅读 · 0 评论 -
IT能够解决所有的商业问题吗?
为什么有“对国内企业来说,不上ERP等死,上ERP找死”的说法?为什么系统开发完了,实施不起来?为什么有的企业用着信息系统还不如按照原来的流程来的好?为什么用户的需求总是变来变去?可能因为他们自己也不知道他们想要什么。Can IT Solve All Business Problems?或许正如文中所说:"Information technology is not a stand-alone sy原创 2004-07-26 13:55:00 · 970 阅读 · 0 评论 -
让UML消失一段时间
昨天我把机器上的Rational XDE和Visio都卸载掉了,因为我们四个月前画的UML图,自从它们被完成后我就没有再看过,也没有使用过XDE的同步功能。这些图对我已经没有意义了,因为我更倾向与使用代码表达,而不是UML图示或大量文档。 而我们作这些文档只不过是管理层的要求,尽管我们曾经有的文档已经足够了。 当然,并不是说UML不好,没用,问题在于,它是否适合你现在项目的情况,它对于你的项目来说原创 2004-07-30 15:32:00 · 1000 阅读 · 1 评论 -
对瀑布模型的解释
对瀑布模型的解释,很形象, Analysis Dream Design Guess and Waffle Build Hack and Play Test Wobble and Groan Deploy Push and Pray Support Duck and Deny虽然现在的项目还在第三个阶段,但是已经提前感到Wobble and Groan的心情了,郁闷大家在开发中是否也原创 2004-07-21 08:42:00 · 1645 阅读 · 0 评论 -
面向对象类设计的一些原则
《敏捷软件开发-原则,模式与实践》一书中的面向对象类设计的一些原则: 单一职责原则:对一个类而言,应该仅有一个引起它变化的原因 开放,封闭原则:软件实体(类,模块,函数等等)应该是可以扩展的,但是不可修改的。 Liskov替换原则子类型必须能够替换掉它的基类型。 依赖倒置原则a.高层模块不应该依赖于低层模块,二者都应该依赖于抽象。b.抽象不应该依赖于细节,细节应该依赖于抽象 接口隔离原则:不应该强原创 2004-07-21 12:58:00 · 1139 阅读 · 0 评论 -
说说对两种源代码管理方式的感受
原文见:说说对两种源代码管理方式的感受 一:按模块分配所有权团队中的每个人在sourcesafe上保留自己的代码,但是自己是看不到未经授权其他人的代码和文档。到发布的时候有SCM把大家的代码那到一起编译生成一个版本。也就是说,项目的每一个工件,都是有所有权的,团队成员根据角色划分,每个角色对工件的所有权不同,最少的就是只拥有自己开发的部分的代码和文档。而项目经理或SCM等角色对全部工件有所有权原创 2006-04-05 18:29:00 · 1630 阅读 · 1 评论