CSDN博客

img kathywp

软件设计深度挖掘(一)

发表于2002/10/25 11:59:00  1331人阅读

软件设计深度挖掘


一 从软件工程说起


   大家都会有这样的困惑:当一个项目摆到我们的面前,我们不知道如何进行分析处理,我们总是不能把握它们的工作量,对于难度我们也没有把握,或者不能确定我们的处理方法是否为最先进或者最稳定等等。我们可以拿出很多书籍进行参考,总想标新立异,但还是没有结果。我们寻找原因,却总是没有答案。下面我们就来谈谈这个问题。


1.1 总体概念
   这里我们不讲解某个函数的用法,某个结构的意义,这里我们讲解的是一个完全的肢解问题的途径。面对一个需求,我们主要作的 便是实现它。我们有两种方法:首先是从头开发,其次是借鉴它山之石。现在的软件开发基本上都是基于第三方的软件平台进行的,我们不愿,也不可能真的从头开发,因此我们要学会引用这种学问。比如我们需要一个媒体播放程序,mpeg1,mpeg2是标准的东西,我们需要重头来过,看着标准进行编码吗?现在的软件业,如果你不是专门的解码公司,这种做法是极为愚蠢的。如果你是软件经理那么你的做法将影响到整个的软件进度,质量,因此为了确保没一步的正确性,我们需要进行正确的分析。现在已经有很多成熟的解码标准,从头开发先不说对于精力的浪费,就算开发出来的代码能快一些,但对于现在的计算机硬件我们有必要在乎它们的差别吗?现在软件所表现出的卖点大部分集中在交互的亲和性,和功能的完备上,我们便不必被限制在软件的纯理论的成绩上。 现在的软件更新速度已经到了前所未有的地步,我们作为开发者,能想到的只有创新超越,但是我们的基础却相对薄弱了一些。一个软件所包含的内在含义不是表面上可以看出来的。比如金山的wps2000 就是一个比较好的国产软件,起初看起来好像并没有想像的复杂,好像每个模块我们都可以写出来,那么你可以试试写写其中的某个功能。你可能会发现你所缺少的东西,整个软件过程的控制?设计模式不明确?数据结构的语言描述不过硬?等等。那么你就需要从头开始,这些基本功并不是需要你全部都记住,但是熟能生巧,巧就是飞跃,就象量变会导致质变一样。  软件是一个大的领域,比如你是开发界面的程序员,那么或许可以对某些数据结构看的轻一些,如果你是作驱动程序的,那么或许你可以对设计模式置之不理。但这并不影响到我们的软件水平,所谓在其位,某其政。从现在软件发展来看,整个软件业象是一个小世界,针对某个领域的程序开发,象windows程序员,linux程序员等等,会成为一个单独的行业。因此这里也有隔行如隔山的问题。我们并不要求程序员具有多么完美的表现,最主要的是将每个程序员的亮点汇聚到一点。因此开发程序最重要的是项目经理--系统分析师。他是我们的带头人,但是现在真正具备项目经理素质的还是比较少。


  1.2 关于软件工程


   软件工程这个领域书籍种类十分的繁多,讲解的深度也是大相径庭。我们这里讨论的软件工程只是从一个程序员的角度来看待软件工程的。也就是最实用的一部分软件工程。现在我们都知道软件业中有个名词叫做软件工程,国内的著作也是举不胜举。但是如果大家看过国外的软件工程的话就会知道,我们的东西只是他们的一部分。自从软件诞生以来中国就一直在追逐世界的先进技术。当计算机产业在国外发展的如火如荼的时候,我们终于觉醒了,我们也要做软件。但这是多么的艰难,所有国外的标准建立起来的计算机体系已经根深蒂固了。于是我们只能借鉴国外的经验,按照别人的要求进行开发。我们追逐者,渐渐的我们学会了一些技巧,但别人的操作系统,开发环境等系统软件却迎面袭来,我们措手不及,我们沉默的接受了一切。这之中当然包括别人的软件工程。于是我们看到的东西都是别人写出来的。我们想实践那些理论,但是我们总是失败,但也有成功。我们就象当年说美国人的几百年的历史,他们用什么来理解我们几千年的文化一样,我们不能完全理解他们的软件工程,我们在努力,我们于是又有了些收获,我们慢慢的明白了他们软件工程的博大精深。这里我就已经理解的部分进行讲述。
1.1.1 我们怎么看待软件工程呢?
不错,软件工程是软件业的一个管理上的mba,但是,现实中很多情况成功者并没有读过管理学。只是他们的行为遵循了管理学的某些定律。所以我们理解软件工程也不必实践全部理论,那是完全没有必要的,就象古人“靠半部论语治天下”,他们也没有完全理解论语一样,但是一定要理解软件工程的精髓。我们要注意我们管理软件时不是为了符合软件工程,而是为了符合软件正确的软件规律,这里不是否定软件工程,只是大家要清楚软件工程会随着实践而改变,但是你解决问题的方法也是有可能符合将来的软件工程的。就象牛顿定律被更新了很多此一样。我们不必生搬硬套。只是没有足够经验的情况下很难有质的飞跃。因此我们可以把现在所有的软件理论当做基础,一种解决问题的基础,当我们需要解决问题的时候可以利用它们,然后加入我们项目特征就可以了。不知道讲清楚了没有:是软件工程符合我们,不是我们追随软件工程。
1.1.2 软件工程的内容
我们都知道软件工程讲解的是软件的管理。现在很多的书籍介绍的都是软件工程的一部分,但它真正包括多少内容呢?我们就来讨论一个软件所包含的内容。
软件工程是随编程理念有所变化的。原来的程序是结构化的,现在的是面向对象的。这就导致了软件工程的不同描述。因此我们在大学里学的大部分是结构化的软件工程描述,现在从软件发展方向来看,这个已经不再适用了。
一个软件就是一个产品,因此软件工程所包括的内容应该包括一个产品的开发过程。因此质量概念是十分强的,这也就是软件工程的发展法则。这个开发过程其实就是一个问题循环解决的过程。它包括了四个截然不同的阶段:状态描述,问题定义,技术开发和方案综述。
状态描述表示了事务的当前状态;
问题定义标识了要解决的特定问题;
技术开发通过应用某些技术来解决问题;
方案综述提交结果给那些从一开始就需要方案的人。


因此软件工程应该包括:
1、 软件项目的管理部分
这是一些基本原则适用与软件的所有阶段。
2、 传统的软件工程部分
包括了原来结构化分析部分的面向对象之前的软件工程。
3、 面向对象的软件工程部分
这是现在最常用的基于面向对象的软件工程方法。
4、 一些特殊的工程处理方法
包括一些比较先进的软件工程理念的技术,但可能没有推广开的那些理论。比如面向用户的软件工程
5、 软件产品过程的分析
这就是作为软件产品来控制的工程理论。这是一个产品的控制,和技术不同。
上面的部分就是软件工程的内容了。真正我们每个人需要了解的却可以不同,因人而异。


谈到软件工程我们不得不讨论一下现在很火爆的认证这个东西。
现在有实力的软件公司都在想办法过什么cmm等等认证,我见
过很多软件公司有种错误的观点:符合标准就可以改变一切。
这其实是大错特错,我们不能盲目附和标准,要搞清楚适用范
围和时间限制。这些标准对于我们国家的软件公司来讲(一般
的公司)是有些太大,什么意思呢,就是太庞大,从机构设置
到开发过程到最终产品提交。我们不能指望几十个人员在三个
月内完成一个大型项目,还要完成所有文档,完成所有的质量保证
程序,完成rose等的设计图,最重要的是不能在开发过程中一
路顺风。我们遇到的技术问题一般会很多。
那我们要符合标准应该是什么意思呢?对于一般的软件公司
很多的标准不适合它们,比如代码量少于10000行的程序一般会


被炒作为中型项目,按照所有的开发步骤,那样会被规则束缚。


都说印度软件产业好,其实他们规范中也有很大的灵活性,


什么都不能妄下定论,就象那个10000行代码的软件,其实可以
不写用例设计图,可以不用概要设计说明、直接达到详细
设计说明中,还可以因项目而异,有的可以省却用户界面设计部分,
有的可以就仅仅使用rup的那些框架文档,自动生成。我们的开发
是灵活的,但是基本的东西却一定要具备,比如:代码规范,
通用开发流程(根据不同的软件行业将会不同),公司软件制度
等等。如果我们的公司还不注意这一点,一定会被其拖垮,自己
还认为做的不够。那些制度大部分是针对大中型企业的,就象window2000
server 很好但是很贵,window 95便宜但是够用了一样,我们要选择
适合自己的就是最好的,随着公司的变大,软件配置管理也会渐渐的
完善,和软件开发一样是叠代渐进的。
软件配置管理是体现一个公司管理层次的大问题。一般公司使用的
可能是sourcesafe,现在很火的clearcase的优点我们也许都知道了。
但是选择还是不选择,我们没有定论,一样的适合最重要。如果配置
clearcase,那么要求单独的一个管理人员,单独的维护,复杂的操作。


我经过了cleaecase培训,但是不具体实践那些东西还是很模糊体会不到它


的好处,但是渐渐的你就会发现它的好处了,但那是多么漫长的时间啊。
用到深处好处就体现出来了,想一想,却发现又有多少个公
司能挺过这个阶段呢?(我认为cleaecase是现在比较好的软件配置工具)


(据我所知很多大的公司有自己的软件标准来取代uml,因此这里不作讨论


我认为是要普及uml比较好)


我们依然循序渐进。


(下面讲解解决问题的方法,将会具体到实现方法,比如图像软件等等)


 

0 0

相关博文

我的热门文章

img
取 消
img