如何写系统分析书

无双

原型法是创建一个原型给客户先用(注意只是试用,用来取得用户意见的)
然后根据用户意见和需求写出代码,那个原型就抛弃掉了

演化模型就是把客户需求分成几个层次 每一期完成一个层次先是重要的 然后是其它的 每一期代码都是在原来的基础上添加 原来那个模型一直在使用不重写

meteor06

thks ；）

蓝色键盘

哦。已经写了这么多的回复。

我始终会认为一个软件工程项目，系统分析设计是首要的，如果这个开头做的不好，以后的麻烦会满天飞－－－维护、升级、扩展、客户化、增加新技术模块等等。除非你的客户属于你自己，你面向的市场只是今朝有酒今朝醉的。

几十年以前的哪种，一两个人搞定一个系统的年代现在也有，但是不符合商业化的要求。设想一下，如果比尔自己不顾用任何员工，就他自己一个人写windows也可以，问题是，他要花多长的时间才能完成windos开发。并且windows怎么让人们去了解，如果比尔生病了或者出了以外，或者自然SW，如果没有项目文档，没有设计资料，没有系统分析书。有多少人会愿意或者能够仔细的阅读他的代码。如果这样，windows不倒闭都难！

软件是一种产业，像印度，程序员就像车间里的工人一样，按照图纸和规定做固定的工作便可。这个图纸便是需求，这个规定便是系统分析的要求。

一个系统分析的一部分就是完成必须的文档，直到能够做到：
当这些说明书完成后，应当能做到：随便找个程序员他都能只通过看某功能模块的设计说明书就能够开始代码的开发而不用再重新思考该怎样去做了，程序员在这里就真的只是一个设计者的实现工具。

蓝色键盘

如果一个人不同意系统分析的重要性，那么这个人要么是顶尖的高手，要么他压根就没做过大型的软件工程项目。

蓝色键盘

说实话，大家都讨厌写文档。尤其是哪些接口设计，概要设计，详细设计。大多数的人也很少的仔细写这些东西，除非部门专门有人检查，没办法才认真一些。
但是，如果你在公司做研发，每年接触者不同的系统，如果没有这些文档的化，估计过个一年半载的你都不承认哪些东西是你做的。如果你离开了公司，没有文档，谁来接手你曾经设计的东西。怎么入手，一行行读代码吗？

无双

不想写文档一个原因是自己觉得没有用
因为自己开发的系统自己知道什么设计的

但是过一段时间后
要你再维护这个系统或是有什么新功能增加时
这时就不知道什么设计的

或在哪里使用了什么特别技术实现
这时没有文档就容易出错

就是你添加的代码没有错
错是在其它关联的地方

到了最后系统越来越乱
这时重写一个也行了

menp9999

[quote]原帖由 "蓝色键盘"]如果一个人不同意系统分析的重要性，那么这个人要么是顶尖的高手，要么他压根就没做过大型的软件工程项目。[/quote 发表：
     
你懂个屁,有些项目的开发就是不需要的.
LINUX有么?
还有银行业务的开发也是不需要的.

无双

我觉得不是不需要
而是因为这个系统已经做了很多个了
并且他们内容都一样

所以不用再重复的分析

LINUX设计的时候也应该考虑一个操作系统应该满足什么功能
然后由此决定系统模块及各模块分工

大的软件如果写到哪里再想下一步的话
代码会很不规范

可以看看操作系统原理：设计与实现那本书
里面对系统的每个部分都进行了详细的研究 就是算法方面也是研究了很多 并说明其它算法的缺点 如进程调度那块

所以好的程序是先有设计后有编码
不然可读性会很差

menp9999

原帖由 "无双" 发表：
我觉得不是不需要
而是因为这个系统已经做了很多个了
并且他们内容都一样

所以不用再重复的分析

LINUX设计的时候也应该考虑一个操作系统应该满足什么功能
然后由此决定系统模块及各模块分工

大的软件如?.........

   
哎,你讲到哪里去了,系统分析哎.

蓝色键盘

menp9999 果真高手

如果没有unix标准（例如posix），不知道linux开发出来，有多少人用，也不知道后来的人怎么添加代码，包括你。

鄙人懂点肤浅的银行项目，不知道menp9999所说的银行项目是什么。

另外，个人观点。作不作系统分析书是一个规范问题，甚至是个习惯。而不是愿不愿意做的问题。