三分钟也谈“系统设计”

    今天，一位部门同事在上午的tea time时间，突然问我：“能否告诉我，如何学习做系统设计呢？对一个新系统，如何从一开始的想法变成一套具有可执行性的设计方案？”

    面对这么一个复杂的而庞大的问题，我以为，任何人的第一感觉是，“这个不是一下子能说清的事！”，至少在那一时刻，我的脑海里蹦出的第一念头就是这个。当时，我没有用我的第一感觉回答他。一是因为，问我问题的这位同事，虽然刚毕业，入司不到半年，但他是一个非常认真上进的人，他问我的态度也是那么诚恳的希望有一个正式的回答；二是因为，这个问题是一个对大多新人来说，都挺有意义的提问，但我自己似乎从没有认真的去思考过。因此，我沉默了.......

    再回想了自己历年的项目经历后，我跟他说，以我个人的感受，进行系统设计大体分以下几个阶段：
1.用户需求分析
  分析用户的初始需求，弄清楚，并尽可能的挖掘用户没说明白的，真实的潜在需求。

2.将用户需求转化成软件需求
  用户需求是我们现实世界的客观需求。而程序设计很重要的过程就是使用计算机上能操作的行为模式来描述用户需求的实现，比如：用户说要收邮件，变成软件需求，就是要设计什么样的操作按钮，什么样的展示窗体，是web形式的，还是客户端形式的。收邮件是用户需求，而使用web应用的操作来收邮件就是软件需求了。

3.在软件需求的基础上运用你学到的各种架构和模式
   比如：开发传统的MIS系统，采用web应用形式，就可以使用人见人知的MVC模型；而如果开发的是网络协议通讯平台，就可能要参考IOCP模型，等等。。

    我的同事又问，那设计是否一定要使用UML呢？
   
    我对他的建议是，UML是一门对设计模型描述用的语言，目标是将你的设计思想使用统一的模式固化下来，以便在团队协作中，你的设计能有一致的理解和继承，但UML本身并不能帮助你实现设计。对于刚开始学习系统设计的人，你完全可以抛开UML，用你自己最自由的方式去开拓你的思维，哪怕是一把白板笔，在白板上乱涂乱画，没人看得懂，都没有关系。如果你的一开始就学习UML，那么你的心思将会重于如何使用UML的符号，而不是如何设计好系统。就好比一个开始学习英语的人用英语作文，他的重点会集中在英语的语法上，而不是文章的构思上。

    交流的时间很短，只有3分钟。我的那位同事听了后若有所思，而对于我自己，却有一种“温故而知新”的痛快感受。

评论

7 楼 yehayeah 2012-09-04  

"UML是一门对设计模型描述用的语言，目标是将你的设计思想使用统一的模式固化下来，以便在团队协作中，你的设计能有一致的理解和继承，但UML本身并不能帮助你实现设计。对于刚开始学习系统设计的人，你完全可以抛开UML，用你自己最自由的方式去开拓你的思维，哪怕是一把白板笔，在白板上乱涂乱画，没人看得懂，都没有关系。如果你的一开始就学习UML，那么你的心思将会重于如何使用UML的符号，而不是如何设计好系统。就好比一个开始学习英语的人用英语作文，他的重点会集中在英语的语法上，而不是文章的构思上。
",同感 。

6 楼 linliangyi2007 2009-02-09  

我不知道 写道

我觉着实际情况中用户最关心的应该我们对需求进行分析后得到的功能需求。
实际用户关心的设计部分可能也就只有界面以及性能等。
架构方面的软件设计实现大部分用户不太关心，只不过对与我们，做专业软件，提高软件竞争力，需要和必须这么做而已。

精辟！

5 楼 我不知道 2009-02-09  

我觉着实际情况中用户最关心的应该我们对需求进行分析后得到的功能需求。
实际用户关心的设计部分可能也就只有界面以及性能等。
架构方面的软件设计实现大部分用户不太关心，只不过对与我们，做专业软件，提高软件竞争力，需要和必须这么做而已。

4 楼 ozzzzzz 2009-02-05  

软件周期这个问题非常严重，据我现在的看法传统教科书上的说法仅仅能当作一些例子进行演示了理解，最多也就是是一个实际应用的时候参考。而实际上应该，则随着企业组织的不同，开发环境的不同，应用场景的不同，客户情况的不同，用户习惯的不同，而有非常大的差别。就一个企业来说，可以逐渐摸索出一套跟自己情况比较适应的生命周期模型。
当然这个部门的内容，同系统设计有关系，但是不是系统设计的一个部分。

3 楼 foolfisher 2009-02-05  

的确，很多规范化的东西可能对于新人的思维发展不是很有利。还有很多要学阿

2 楼 linliangyi2007 2009-02-05  

cprogrammer 写道

这不是在说软件生命周期的前几部分吗？ 

这个问题应该是仁者见仁，智者见智吧。

1 楼 cprogrammer 2009-02-05  

linliangyi2007 写道

    今天，一位部门同事在上午的tea time时间，突然问我：“能否告诉我，如何学习做系统设计呢？对一个新系统，如何从一开始的想法变成一套具有可执行性的设计方案？”

    面对这么一个复杂的而庞大的问题，我以为，任何人的第一感觉是，“这个不是一下子能说清的事！”，至少在那一时刻，我的脑海里蹦出的第一念头就是这个。当时，我没有用我的第一感觉回答他。一是因为，问我问题的这位同事，虽然刚毕业，入司不到半年，但他是一个非常认真上进的人，他问我的态度也是那么诚恳的希望有一个正式的回答；二是因为，这个问题是一个对大多新人来说，都挺有意义的提问，但我自己似乎从没有认真的去思考过。因此，我沉默了.......

    再回想了自己历年的项目经历后，我跟他说，以我个人的感受，进行系统设计大体分以下几个阶段：
1.用户需求分析
  分析用户的初始需求，弄清楚，并尽可能的挖掘用户没说明白的，真实的潜在需求。

2.将用户需求转化成软件需求
  用户需求是我们现实世界的客观需求。而程序设计很重要的过程就是使用计算机上能操作的行为模式来描述用户需求的实现，比如：用户说要收邮件，变成软件需求，就是要设计什么样的操作按钮，什么样的展示窗体，是web形式的，还是客户端形式的。收邮件是用户需求，而使用web应用的操作来收邮件就是软件需求了。

3.在软件需求的基础上运用你学到的各种架构和模式
   比如：开发传统的MIS系统，采用web应用形式，就可以使用人见人知的MVC模型；而如果开发的是网络协议通讯平台，就可能要参考IOCP模型，等等。。

    我的同事又问，那设计是否一定要使用UML呢？
   
    我对他的建议是，UML是一门对设计模型描述用的语言，目标是将你的设计思想使用统一的模式固化下来，以便在团队协作中，你的设计能有一致的理解和继承，但UML本身并不能帮助你实现设计。对于刚开始学习系统设计的人，你完全可以抛开UML，用你自己最自由的方式去开拓你的思维，哪怕是一把白板笔，在白板上乱涂乱画，没人看得懂，都没有关系。如果你的一开始就学习UML，那么你的心思将会重于如何使用UML的符号，而不是如何设计好系统。就好比一个开始学习英语的人用英语作文，他的重点会集中在英语的语法上，而不是文章的构思上。

    交流的时间很短，只有3分钟。我的那位同事听了后若有所思，而对于我自己，却有一种“温故而知新”的痛快感受。

这不是在说软件生命周期的前几部分吗？