软件开发过程中的几个问题

一、过程问题

很多企业员工在使用UML的过程中，只是进行了领域建模，没有进行用例建模，这样是不能最大可能地发挥UML的优势的，因为该组织的软件开发过程不是用例驱动的。

UML对使用它的软件开发过程的要求是用例驱动，以架构为中心，迭代和递增的开发，如果软件开发组织的软件开发过程不能满足这三点要求，那么UML的使用效果就会大打折扣。也会产生一些问题，有些组织在使用UML之后，发现前期花很长时间设计的模型到了项目的中后期和真正的开发成果相去甚远，以至于全都束之高阁了，如果产生这样的问题，就应该仔细研究一下组织的软件开发过程，是否满足上述三点要求，如果软件开发过程不满足迭代的开发，模型没有随着进度改进，这种问题就很容易出现。

 

用例驱动也是尤其重要的，这意味着用例贯穿于软件开发的始末。

二、面向对象分析设计中的问题

一、重用问题

OO一大优势就是支持重用设计，可是很多软件开发组织使用了面向对象得编程语言，却不知道该如何实施重用，重用级别仍然处于代码级。

 

如何从代码级到组件（run time）和构件级，再到架构、分析模型和域模型的重用呢？

如果组织规模处于中等规模以上，有足够的人力资源的话可以成立专门的可重用构件的专门团队，他们针对组织的业务逻辑，现有的产品和将要开发的产品，进行总结并提取出可以重用的组件。建立构件库，可以供使用者方便查询。

 

如果组织规模不大，没有可能进行上述工作，可以由下至上的实施，软件分析设计人员在进行分析的时候就要足够重视重用的问题，进行高内聚低耦合的设计，对有共性的东西进行提取和抽象，这样在开发过程中进行构件的累积，并组织成可方便查询的库，逐步开展重用工作。

 

如果想一步到位地实施重用，是有风险的，HP公司曾经购买大量的可重用构件库，大规模的实施重用，结果是彻底失败了。原因如下，首先，购进的构件库的质量不一定能保证，然后是是否适合公司的实际情况，人员对构件库的熟悉和理解，以及和实际业务逻辑的贴近程度。

二、需求捕获及变更问题

如何与客户合作，获取需求。如：有些需求人员找客户中的领导，遇到推托，就放弃了需求获取，想当然的开始做软件系统。有些人觉得面对客户问这问那怕被人认为很无知，也就放弃了需求捕获。

 

有位专家说过，需求其实很少变更，只是你从来就没有获取到。对某些传统行业的信息化，我很赞同这位专家的观点，在项目中也有体会，他们的工作流程至少也实施了几年了，不会轻易就变更。

 

需求分析中的学问很大，很多软件开发组织在这方面能力都有欠缺，造成项目大量的修改和返工，严重影响进度和质量，造成团队气势低落。

 

最经典的错误问题，如：你们的工作流程是什么样的？等等。

三、过度设计问题

实施迭代式开发来避免过度设计，把握好设计的详细程度。

四、程序员镀金问题

　　这个问题其实是项目管理问题，但只有技术管理者才更容易及时发现这类问题，并可通过及时沟通和过程的迭代来解决。

五、分析设计细节上的问题

例如用例图设计中的错误，惯用设计方法的遵守（比如有人把java包名设计成大写字母开头等类似问题）、类的设计（把类设计成一个包，什么都包括），面向接口设计和编程，避免过早关注细节，以及程序设计中需要注意的问题，方法命名（例如，isNull()方法里面的逻辑根名字刚好相反）、变量命名、程序风格，程序注释等等。

六、工具使用的问题

面对复杂份繁的工具，很多人都很困惑，用什么好呢？适度使用工具，选择合适的工具，工具和方法论并重，避免garbage in, garbage out，真正理解方法论和分析设计方法，而不是流于形式。选择并充分发挥集成开发环境的价值。

八、做好技术型的领导

这些问题很重要，比如建立技术型的团队，激励等等。