在软件开发的过程中，从林锐的《软件工程思想》中知道，有三个基本策略：复用，分而治之，折衷。
对于复用我的理解是，使手中的已经成型的资源再次用于软件的开发过程中。对于现在的复用技术，不仅仅是早期的代码级的。而在现在的复用技术中存在着这样不同级别的复用形式：
一：代码复用。
这就是传统意义上的复用，但这不是简单的在一个系统中多次使用写过的代码，那称为共享，而不是复用。也不是把原来的代码拿过来做了一定的修改重新再用。我觉得这些都不是真正意义上的代码复用。我所理解的代码复用是：在做软件开发的时候尽可能的把代码模块封装成类似于组件的形式，在不断的积累后形成了属于自己公司的复用库，在以后的软件开发中只要从库中进行简单的调用，这才是真正意义上的代码复用级别。
二：设计复用
对于这一级的复用，其实是很重要的，因为对于设计结果的抽象要比源程序的抽象容易的多，在源程序中因为存在着差异性很大的业务逻辑，而使得抽象更困难。而设计结果相对就比较容易了，因此这一级的复用受现实环境的影响就少了。复用时做要做的修改就会很少。对于这一级的常用复用在于，复用一些现有系统中的设计构件。或者在无任何实际应用下，有目的的开发一些专门用于复用的设计构件。
三：分析复用
这一级的复用有是在设计复用之上，对于这一级的复用，他不用关心下面是采用的什么样的设计模式，他所强调的是在某一个问题域上对于特定的事物进行分析层的抽象。这种复用对于现实环境较之设计复用更不敏感。当前对于分析复用，途径有三种，从现有系统的分析结果中提取可复用构件用于新系统的分析；用一份完整的分析文档作输入产生针对不同软硬件平台和其它实现条件的多项设计；独立于具体应用，专门开发一些可复用的分析构件。
四：测试复用
复用技术已经贯穿整个软件开发过程，在像测试这样的环节中也存在着复用。但其实这一级的复用不能是单独的一级。在测试中的复用主要还是在于测试用例和测试过程上的复用。但其实这样的复用还是有一定的局限性，并不能做到类似于上面各级的复用，准确点说是类似于代码复用的级别。但在测试信息上的复用也很好的提高了软件开发的效率。
而对于分而治之的软件开发策略，讲求的是当遇到一个大的问题的时候，采取分而治之，逐个击破的方法，将大的问题转化成小的易解决的问题，这样我个人觉得首先能很好的解决问题，再者就是将较大细度的问题分解成较小的后，也便于将细度小的功能模块封装成组件，利于组件间的复用，也提高了软件开发的效率。但在分而治之的时候要注意的就是不能如挥刀切肉一样的。一定还要保持各个小细度模块之间的各种联系。其实讲一个大的问题分解成多少个小细度的模块这本身也是一门很讲究的学问。因为不是细度越小学好，做个不恰当的比喻，当你把一只鸡切成足够小的时候你就会分不清那个是头，那个是腿了，这显然不是我们想要的结果。而且在分的时候还要考虑的就是分成这样的细度的模块的时间是不是已经超过了你去分析一个整的问题的时间。我觉得对于软件公司来讲，时间无疑是成本的很大开销。
第三个软件开发的策略就是折衷。这里还是引用林锐的《软件工程思想》中的一个很有意思的例子———解决《鱼和熊掌不可兼得》的问题
问题提出：假设鱼每千克10元，熊掌每千克一万元。有个倔脾气的人只有20元钱，非得要吃上一公斤美妙的“熊掌烧鱼”，怎么办？
解决方案：化9元9角9分钱买999克鱼肉，化10元钱买1克熊掌肉，可做一道“熊掌戏鱼”菜。剩下的那一分钱还可建立奖励基金。
这个例子看似很幽默，其实我觉得包含了在软件开发中一个很实际的道理，虽然我的 软件开发经验很少，但是我知道在程序员中存在着很多的追求完美的人，他们力图把自己的软件做到天衣无缝，以我个人的感觉，这只是个美好的人生追求，因为这是不可能实现的。我知道在无论是哪个软件中都不可能是完美的，虽然现在也许是无懈可击的，但那只代表了以现在的水品还没有人能发现这之中的问题。而且对于企业级的公司来讲，考虑的是软件的收益，如果一群程序员为了一个其实不是很实用的功能奋斗了很久，最后的客户却说他们什么都没做，我想这样的心情是很难想象的。因为客户他关心的是你能不能满足他的要求，至于其他的他认为没有必要的功能，都只是一堆没有用的代码，（在客户的眼里），当然这不是一种对技术的不严谨，我只是想说，在软件开发过程中，作为商用软件最关心的就是用户是否满意，对于其它的，折衷是最好的解决方案。
这是我所总结的关于软件开发的三个策略，当然着只是我从个中资料中所理解出来的，其中的观点很有可能就是错误的，我只是把我的真实想法说出来了。
下面我想谈谈我在软件需求方面的一点看法。
在我看来，软件工程的每一个环节都不能松懈，但是软件的需求分析这是最重要的，他所决定的是整个软件是不是符合要求，整个软件是不是严格的按照客户的要求来设计，来编码，来部署的。它只要有一点点的偏差，对于整个软件所造成的也许就是致命的打击。
软件的需求分析讲的其实就是个是什么和为什么的问题 ，其分为：
业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（ use case）文档或方案脚本（ s c e n a r i o）说明中予以说明。
功能需求功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求（摘自《软件需求》）
其实我看这三个单分类的理解是，这三个分别从三个角度来谈软件需求，业务需求是从客户角度，用户需求是从用户角度，而功能需求是从开发者角度。这也就说明了当一个软件在开发的前期要做的需求分析不仅仅是对客户的或者是对用户的，而是要包含开发者在内的三方进行需求分析。通常在软件开发中把可行性分析跟需求分析是放在一起做的，这是因为可行性分析要做的是：做还是不做，上面讲到过需求分析是：是什么和为什么，但同样也可以理解为：做什么和怎么做的问题。显然可行性分析是和需求分析息息相关的。
在可行性分析的过程中肯定要加上需求分析的一定内容，同时还要考虑资源，团队实力，工作计划等的是否符合开发此软件的能力。
然而在需求分析阶段，一些资料上把这个过程称为是需求开发，主要包含了一下这几项任务：
一：绘制系统关联图
二：创建用户接口原型
三：分析需求可行性
四：确定需求的优先级别
五：为需求建立模型
六：创建数据字典
七：使用质量功能调配
从这里也能看出可行性分析与需求分析是密不可分的。
我自己的一点理解，其实这些都是我对各种媒体上关于软件工程和复用的研究的一点心得，不对的地方还望大家多多指教~~~有礼了~~
