| meteor06 回复于：2003-06-23 14:32:21
|
不知道楼主对与怎样与客户沟通，有
什么好的经验？能说说吗？
记得软件工程中提到，可以先做一个较为简单的模型
将基本功能做演示，在根据客户需求修改，在实际中是否有如此做的，可行吗？
|
| 无双 回复于：2003-06-23 17:52:27
|
我觉得那就是演化模型或是原型法
可以查找一下论坛中软件生命周期讨论
这样的话可以更好的发现客户早期需求
这样确实是一个比较好的办法
|
| menp9999 回复于：2003-06-24 08:27:54
|
这个东东,有时候简直就是放屁.成为无需为却又不得不为的"金科玉律".呵呵.
|
| meteor06 回复于：2003-06-24 08:41:11
|
[quote:b86cd3f068="menp9999"]这个东东,有时候简直就是放屁.成为无需为却又不得不为的"金科玉律".呵呵.[/quote:b86cd3f068]
不要光想自己，要为后来人服务
如果以后别人维护，没有详细的文档资料
只是看原程序，那会很痛苦的
（不过要是我自己，也会偷懒少写点  ops: ）
|
| 大连老K 回复于：2003-06-24 08:51:39
|
"系统的扩展及更新"在分析和设计时要考虑到这一点和实现这一点是非常难的一件事情。
|
| menp9999 回复于：2003-06-24 08:58:00
|
[quote:8541f8864c="meteor06"]
不要光想自己，要为后来人服务
如果以后别人维护，没有详细的文档资料
只是看原程序，那会很痛苦的
（不过要是我自己，也会偷懒少写点 ops: ）[/quote:8541f8864c]
拉倒吧,系统分析,谁看呀.我看的几个系统分析纯粹是他妈的放屁.
不过为什么软件工程的形式,还偏偏要充在里面.
|
| meteor06 回复于：2003-06-24 08:59:32
|
[quote:ac845f4e3a="无双"]我觉得那就是演化模型或是原型法
可以查找一下论坛中软件生命周期讨论
这样的话可以更好的发现客户早期需求
这样确实是一个比较好的办法[/quote:ac845f4e3a]
刚拜读了版主大作，有几个问题
1。这些都是软件工程中所提到的方法，相信所有学计算机的都大体学过
按理说在工作中应该按照要求来做工程，但是接触到的有限的几个项目
据了解都没有严格按照执行，只有简单的设计，完整的文档往往是项目
完成后补写的，而且经过一段时间修改维护后，文档就更不全了，只有
初始规划的文档，修改的文档几乎没有。
因为接触的开发项目不多，且仅是听开发人员诉说，不知道版主和各位在
实际工作中碰到的情况如何，也就是国内软件行业现状到底怎样，非常
想了解，能否告之
2。看了版主所提的演化模型，
在开发出核心系统后，根据客户需求进行修改，重新开发的系统是建立在
以开发出的核心系统之上，还是初次的核心系统仅作为参考？
|
| 无双 回复于：2003-06-24 10:21:28
|
系统分析是为了知道用户需求
如果用户需求改变很大的化
系统结构可能都要重写
后期重写不 如早期就发现并重写
这样可以减少成本
|
| 无双 回复于：2003-06-24 10:33:35
|
1 国内这方面确实不是很好, 但是对大软件来说都是有设计先
小软件的话, 则是先有代码, 然后再补充文档了
要想在初期有很好的文档, 并且保证文档的同步确实很难, 因为需求的改变, 或是程序的改变都要对文档进行同步, 在整个系统没有完全定下来前这样工作量很大,因此会拖延项目进度 我在大单位中是先有设计文档,然后评审 然后编码 后面开发中的文档也是没有同步, 开发完了再做一次同步
早期的文档主要是为了各方面协调用 开发过程中的更改通过多方协商然后定下来, 但是定下来后也会发一个文档给每个人的
后在一家小公司工作 他们不但没有文档 代码也没有注释 这可能是与小公司对效率的要求很高 不想把时间花在这上面 另外开发的软件也是小软件 所以通过大家讨论可以解决问题
但是没有设计代码写到后面看起来就觉得很乱 所以要增加新功能 增加到了一定程序代码读起来就觉得很困难了 而且就是相同功能的代码不方便重用
觉得如果有设计有文档的话 可以把程序做得更好 并且到了后面 有良好设计的软件继续添加功能会更方便
|
| 无双 回复于：2003-06-24 10:37:16
|
原型法是创建一个原型给客户先用(注意只是试用,用来取得用户意见的)
然后根据用户意见和需求写出代码,那个原型就抛弃掉了
演化模型就是把客户需求分成几个层次 每一期完成一个层次先是重要的 然后是其它的 每一期代码都是在原来的基础上添加 原来那个模型一直在使用不重写
|
| meteor06 回复于：2003-06-24 10:44:07
|
thks ；）
|
| 蓝色键盘 回复于：2003-06-24 11:09:53
|
哦。已经写了这么多的回复。
我始终会认为一个软件工程项目，系统分析设计是首要的，如果这个开头做的不好，以后的麻烦会满天飞－－－维护、升级、扩展、客户化、增加新技术模块等等。除非你的客户属于你自己，你面向的市场只是今朝有酒今朝醉的。
几十年以前的哪种，一两个人搞定一个系统的年代现在也有，但是不符合商业化的要求。设想一下，如果比尔自己不顾用任何员工，就他自己一个人写windows也可以，问题是，他要花多长的时间才能完成windos开发。并且windows怎么让人们去了解，如果比尔生病了或者出了以外，或者自然SW，如果没有项目文档，没有设计资料，没有系统分析书。有多少人会愿意或者能够仔细的阅读他的代码。如果这样，windows不倒闭都难！
软件是一种产业，像印度，程序员就像车间里的工人一样，按照图纸和规定做固定的工作便可。这个图纸便是需求，这个规定便是系统分析的要求。
一个系统分析的一部分就是完成必须的文档，直到能够做到：
当这些说明书完成后，应当能做到：随便找个程序员他都能只通过看某功能模块的设计说明书就能够开始代码的开发而不用再重新思考该怎样去做了，程序员在这里就真的只是一个设计者的实现工具。
|
| 蓝色键盘 回复于：2003-06-24 11:12:35
|
如果一个人不同意系统分析的重要性，那么这个人要么是顶尖的高手，要么他压根就没做过大型的软件工程项目。
|
| 蓝色键盘 回复于：2003-06-24 11:21:01
|
说实话，大家都讨厌写文档。尤其是哪些接口设计，概要设计，详细设计。大多数的人也很少的仔细写这些东西，除非部门专门有人检查，没办法才认真一些。
但是，如果你在公司做研发，每年接触者不同的系统，如果没有这些文档的化，估计过个一年半载的你都不承认哪些东西是你做的。如果你离开了公司，没有文档，谁来接手你曾经设计的东西。怎么入手，一行行读代码吗？
|
| 无双 回复于：2003-06-24 12:34:28
|
不想写文档一个原因是自己觉得没有用
因为自己开发的系统自己知道什么设计的
但是过一段时间后
要你再维护这个系统或是有什么新功能增加时
这时就不知道什么设计的
或在哪里使用了什么特别技术实现
这时没有文档就容易出错
就是你添加的代码没有错
错是在其它关联的地方
到了最后系统越来越乱
这时重写一个也行了
|
| menp9999 回复于：2003-06-26 09:39:36
|
[quote:b0993df19c="蓝色键盘"]如果一个人不同意系统分析的重要性，那么这个人要么是顶尖的高手，要么他压根就没做过大型的软件工程项目。[/quote:b0993df19c]
你懂个屁,有些项目的开发就是不需要的.
LINUX有么?
还有银行业务的开发也是不需要的.
|
| 无双 回复于：2003-06-26 09:58:13
|
我觉得不是不需要
而是因为这个系统已经做了很多个了
并且他们内容都一样
所以不用再重复的分析
LINUX设计的时候也应该考虑一个操作系统应该满足什么功能
然后由此决定系统模块及各模块分工
大的软件如果写到哪里再想下一步的话
代码会很不规范
可以看看操作系统原理：设计与实现那本书
里面对系统的每个部分都进行了详细的研究 就是算法方面也是研究了很多 并说明其它算法的缺点 如进程调度那块
所以好的程序是先有设计后有编码
不然可读性会很差
|
| menp9999 回复于：2003-06-26 14:53:00
|
[quote:267b974d6e="无双"]我觉得不是不需要
而是因为这个系统已经做了很多个了
并且他们内容都一样
所以不用再重复的分析
LINUX设计的时候也应该考虑一个操作系统应该满足什么功能
然后由此决定系统模块及各模块分工
大的软件如?.........[/quote:267b974d6e]
哎,你讲到哪里去了,系统分析哎.
|
| 蓝色键盘 回复于：2003-06-27 17:14:33
|
menp9999 果真高手
如果没有unix标准（例如posix），不知道linux开发出来，有多少人用，也不知道后来的人怎么添加代码，包括你。
鄙人懂点肤浅的银行项目，不知道menp9999所说的银行项目是什么。
另外，个人观点。作不作系统分析书是一个规范问题，甚至是个习惯。而不是愿不愿意做的问题。
|
| menp9999 回复于：2003-07-01 10:22:03
|
[quote:5843c43536="蓝色键盘"]menp9999 果真高手
如果没有unix标准（例如posix），不知道linux开发出来，有多少人用，也不知道后来的人怎么添加代码，包括你。
鄙人懂点肤浅的银行项目，不知道menp9999所说的银行项目是什么。
另外，个?.........[/quote:5843c43536]
关于LINUX的问题,你自己去找资料去.
关于银行项目的问题,你去问问他没有有谁做了系统分析的,呵呵,就以城市综合网的项目为例子,你去打听打听,那些所谓的系统分析,不过是补了为了骗领导的.
|
| menp9999 回复于：2003-07-01 10:33:34
|
[quote:17a90aa839="无双"]我觉得不是不需要
而是因为这个系统已经做了很多个了
并且他们内容都一样
所以不用再重复的分析
LINUX设计的时候也应该考虑一个操作系统应该满足什么功能
然后由此决定系统模块及各模块分工
大的软件如?.........[/quote:17a90aa839]
大家总是喜欢从软件设计的角度去考虑问题,其实没有必要.就象有句"功夫在诗外"一样的道理,譬如银行项目,会计制度设计的本身就是包含了从软件设计角度来说系统设计了,所以再来做一遍,只不过是走走形式,骗骗人了.当然有一个东西是会计制度设计的时候没有考虑的,那就是软件升级.制度改变,以前的会计数据怎么办的问题,只是这些东西不是那帮高手所能考虑的问题.因此嘛,系统分析是不需要的.
|
| 无双 回复于：2003-07-01 11:08:56
|
那不是啊
会议只是需求分析的一部分
系统分析就是想怎样让一个系统有更好的可维护性与可扩展性
以后添加功能时方便
需求是要知道一个软件能完成什么功能
|
| menp9999 回复于：2003-07-01 13:59:00
|
[quote:89df9f2a41="无双"]那不是啊
会议只是需求分析的一部分
系统分析就是想怎样让一个系统有更好的可维护性与可扩展性
以后添加功能时方便
需求是要知道一个软件能完成什么功能[/quote:89df9f2a41]
别拉性来吓人,我好怕怕.可扩展不如说错误的源泉.
|
| 无双 回复于：2003-07-01 16:27:18
|
如果设计不好的话
那么会是错误的源泉
但是需求总是在不断变化
不可能有个小需求就重写一遍
所以良好的设计还是需要的
除非想代码写完后就不用了
发的设计可以在源码级共享
CMM就是为了这个提出的（虽然到了中国后也变了质 ,变成一种认证了）
|
| forkson 回复于：2003-07-02 18:51:44
|
如果没有正式的文档说明，客户只是在口头上向你传达需求或更改，最后死得很惨的是自己！一点体会。
|
| 无双 回复于：2003-07-02 19:53:13
|
其实最好是有一个统一的需求
就是说客户提需求时不要一点一点提
而是一次提很多
这样改进会比较快
|
| menp9999 回复于：2003-07-03 08:46:44
|
[quote:7fc0b77943="forkson"]如果没有正式的文档说明，客户只是在口头上向你传达需求或更改，最后死得很惨的是自己！一点体会。[/quote:7fc0b77943]
一点体会,我做项目时,不要客户自己提供,而是我比客户更专家而已,呵呵.
|
| 一无所有 回复于：2003-07-03 13:30:34
|
[quote:4f66d382cc="无双"]我觉得那就是演化模型或是原型法
可以查找一下论坛中软件生命周期讨论
这样的话可以更好的发现客户早期需求
这样确实是一个比较好的办法[/quote:4f66d382cc]
无双兄可能没有完全理解楼主的意思，
我看楼主应该是讲的迭代开发。
是在一个模型上不断完善，而不是抛弃以前的原型
|
| 一无所有 回复于：2003-07-10 08:26:16
|
文档在总个项目的生命周期都是很重要的。
如果我们把文档当成是一种任务，而不是一种资源，
那将是我们自己的损失。
|
| 无双 回复于：2003-07-10 19:42:23
|
老大
让你不工作一个月看
就知道什么样的感觉了
|
| 蓝色键盘 回复于：2003-07-10 18:48:36
|
我以前作项目讨厌写文档，但是吃了几次苦头。
现在觉得文档写起来麻烦，但是用处的确不少。
尤其是系统需要改造的过程中。
系统分析书可以不写，但是这个系统的框架在一个人的脑子中，例如像menp9999，我觉得他完全可以不写，但是如果他离开了那家公司，谁来维护。还有一个问题是，就算是自己当初设计的系统框架，项目多了，也总有记得不是很清楚的地方，如果维护产品的人经常的修改系统的某些地方，总有一天会被更改的面目全非。
|
| 无双 回复于：2003-07-10 19:02:53
|
一般来说文档主要的就是和代码难同步
所以很详细的文档很难写
也没有什么用
总体框架是应该有的
|
| 蓝色键盘 回复于：2003-07-10 19:17:04
|
级别: 法师
注册时间: 2002-11-21
最后登录: 2003-07-10
帖子总数: 7388
精华帖子: 36
原创精华: 2
来自: 浙江杭州
在线状态: ...在线...
无双兄，我还是喜欢大天使这个级别，可惜是什么精灵使了！
|
| 傲孤子 回复于：2003-07-20 14:00:20
|
那不是呀！
一个软件还是应该先写文档，再做这样做到有计划，
或许可以省略多不必要的重复！·
|
| lqy009 回复于：2003-08-01 17:12:28
|
文档是大家还没有重视的东东！
|
| jinijxta 回复于：2003-08-04 21:43:14
|
文档这东西在开发的时间可能没有人愿意写，在系统维护时读代码还是很麻烦的。软件业能否与建筑业一样，上午有人不干了，下午找一个人就可以继续上午的工作了。目前的现状是不能。
系统分析不可能全部预先了解客户的所有需求，只能提供一个较好的框架，在必要的时候重新组装商务逻辑。从架构来讲还是比较重要的。不需要系统分析的项目还是有一些，做到后边集成和配置的时候太麻烦。
|
| 无双 回复于：2003-08-04 22:26:04
|
但是软件的规范化需要有现汇的文档
无论从生产效率还是其它方面 文档都是很重要的
|
| jinijxta 回复于：2003-08-05 19:23:14
|
我用到一个公司的文档，约有2米高。仔细一读，没几份文档可以用来进行编码。很多时候文档是程序员送给老板安心，其实没用的东西。
我曾试着要求程序员按ISO软件工程模板书写文档，阻力太大。因为项目是时间驱动的，先将产品做出来再说。
|
| 无双 回复于：2003-08-05 19:34:39
|
习惯了就好了 不过很长的文档没有几个人看的
文档主要是说出个大概 几百页的文档不知道会有谁从头看到尾
|
