ddxkjddx的专栏

<br /><br />对软件复用的划分，大致将它分成四种类型：<br />   1.代码级复用：就是通过编写大量的公共类，公共函数等等,供开发人员直接使用。<br />   2.组件级复用：通过将功能的组件化封装，对外提供一组或多组的API接口。<br />   3.模块级复用：在我们开发的项目或者产品中，会发现大量重复的功能模块，比如用户管理，机构管理等等，如果我们在这些模块设计的时候，注重一下扩展性，那么可以应用到有其它类似功能的项目中。在这个级别需要一定的项目的积累，否则在模块功能上以及实用性上会遭

<br /> <br />这七十五条，是我这些年来，尤其是在微软工作两年来的体会的总结，关于如何用正确的方法来写出质量好的软件的体会的总结。或许看似平淡无奇，但大音希声，这七十五条的效用，未必及不上那几十页几百页的体系，却远远比那好用：<br /><br />1. 你们的项目组使用源代码管理工具了么？<br />2. 你们的项目组使用缺陷管理系统了么？<br />3. 你们的测试组还在用Word写测试用例么？<br />4. 你们的项目组有没有建立一个门户网站？<br />5. 你们的项目组用了你能买到最好

1，B/S目前是大势所趋，但由于相对cs系统而言，在很多方面都不能被B/S取代，如在运行速度、数据安全、人机交互等方面， 所以我们不得不面对折中选择，于是平台厂商们提出了c/s架构结合智能客户端感应技术，大大降低C/S架构的系统部署成本。 2，随着企业的发展，客户需求的系统越来越多，如果还是基于传统开发，那么如果设计不合理，必将形成一个一个的信息孤岛，如何将这些系统有效整合，相信都是大家非常头痛的一件事情，但是倘若一开始采用平台化开发技术，所有的系统都集中在一个开发库下进行开发设计，根据公司后续的需要，在原

<br />几个月前，公司委派我负责一个难啃的骨头式软件开发项目。公司把我从一线开发设计组调到项目需求组，主要负责客户需求调研、确认和沟通的管理工作。对于此项工作我原来认为压力并不大，因为对于软件开发的需求调研我可谓轻车熟路，加之自己有一线开发和设计的经验，工作起来应该会是一帆风顺的。但没有想到的是才过了一个月左右，我却发现自己陷入了沟通管理的困境之中。<br /><br />　　在我的多年开发经验中，我深知道沟通不当不仅会造成需求失真，而且还会给项目带来严重的成本损害，甚至会导致项目失败。例如，如果需求在

软件产品的需求可以分为功能性需求和非功能性需求，其中非功能性需求是常常被轻视，甚至被忽视的一个重要方面。其实，软件产品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。　　所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。下面对其中的某些指标加以说明。1、功能性　　功能性指与一组功能及其指定的性质有关的一组属性，这里的功能是指满足明确或者隐含