- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】IT教师手记--系统开发与设计（一）开发基本概念 -- redbud
家园 【原创】IT教师手记--系统开发与设计（一）开发基本概念 IT教师手记--系统开发与设计（一）开发基本概念
by Redbud 2010
前言
网络生涯已久，大部分时间都写一些风花雪月的东西，所谓灵魂的尖，玄之又玄，久了有些厌倦，生命不单单是虚幻，还有真实。想表达一些更加严肃，更加有条理的东西的想法已久，但是缺乏一个好的环境，就如同种子没有土壤。
感谢朋友推荐我来到西西河，发现这里有许多人在讨论IT，哲学，科学，等等，不禁有点一见钟情的感觉，写点东西吧。写什么呢？在河里是新兵，据说这里的大牛很多，让我别写了。一直被训练要critical thinking，就是说，拿着再强的文学作品，我要找出它的缺点，再好的人，要找出其软弱的地方，再实用的理论，要找出其盲点，当然，你如果能找出缺点来，一定知其优点的。只有这样，你才能了解别人和自己。说说自己的优点是表达能力强，肯吃苦，缺点是实践基础不扎实。
刚开始教书，而且教的是商业信息系统，千变万化啊，觉得力不从心，要到处找案例，到处补充知识，灵机一动，不妨将自己所知道的一点知识整理出来，一方面分享给大家，优点是比较系统，缺点是缺乏实践经验，不如让大家提点意见，可以对自己的专业知识成长有帮助。再次说明，这里如果有开发实践经验的弟兄姐妹们（当然弟兄们多，据我所知，搞开发的不是女人干的活，据说老得很快还顾不上家），如果我这里有跟实际脱节，以及知识不完备的地方，请一定指正出来，另外，很希望大家可以多提供例子和讨论，这是我写这篇文章的初衷。
系统开发与设计（一）基础的理论知识
所谓系统开发与设计，许多人听起来是比较悬的，若没有参与过开发与设计的人，听起来更深觉得有点头大，记得当年在国内参加信息部的考试，有个高级程序员的考试，再上面就是系统分析员了，跟着师兄一起去考，他考分析员，我考高程，一次考过，他考几次才考过了，告诉我说，系统分析员拿钱多，职业前途好。反正我最后也没有去编程，我的师兄好像也没做系统分析员。这是题外话，当年的印象就是，系统分析员是个神秘的角色。
等自己真的要开始教系统分析的课程是很多年以后了，很多种课本，经典的，新的，再加上老的，有十几本吧，出版社还在不断发新版本给我，又加上新的概念，UML,OO，更让人有些迷失，刚将哪些基本的东西给一个入门的人讲，让他们明白什么是系统开发与设计呢？下决心理理这门课，是在遇到一个做了7年系统开发与设计的从业经验人员，细细谈来，理论和实践是有这么一个gap，是在教科当中需要注意的，那么，何不来到实践性的论坛来，跟大家一起讨论呢？
系统开发与设计（英文简称SAD），是一种方法，就是指导从系统的初始计划(Planning) 到分析(Analysis)、设计 (Design)、安装(Implementation)的严谨的方法，主要包涵刚才提到的四个阶段。这门课在商学院通常是一个学期，英国是22个小时的课，美国是34小时，中国应该也是34个小时，在计算机系和信息系统专业可能是两个学期，一个学年，通常教课的方式采取的是案例+分析的方式，考试方式一般是group project，有的学校会用上一半project，一半笔试。花费这么多的时间来上这门课，目的是什么呢？
首先看看SAD项目上面所投入的金钱，以及企业界SAD项目的成功情况。
根据Standish公司的1995年的报告（最近的数据看不到），美国每年花在SAD项目上面的钱是2500亿(250billion)，每年大约175000个project，平均下来，每个大型的SAD项目，投入大约是2322000美金，中型是1331000美金，小型的是434000美金，可是这中间的大部分的都是失败的。
项目的失败和成功，不是简单的黑白那么清楚。有一个公司叫做Standish Group，每年都会发布一项Standish Chaos Report（有点意思是项目开发一片混乱）来调查项目的成功和失败率，他们有一个标准，将项目的结果分了三类，Successful (成功), challenged（不理想）, and failed （失败）. SAD近几年的成功率也只有30%左右，早年如1994年只有16%。
1994 1996 1998 2000 2002 2004 2006 2009
16% 27% 26% 28% 34% 29% 35% 32%
53% 33% 46% 49% 51% 53% 46% 44%
31% 40% 28% 23% 15% 18% 19% 24%
所谓成功，就是按时，符合预算，以及达到了预期设计的功能，不理想的情况就是延期、超预算、以及达不到预期的功能。这个可以用Nike公司的市场预测系统的失败来说明，nike市场预算系统开发过快，以至于需求分析没有弄明白，导致的后果是库存失误，造成了其某些鞋子生产不足，某些鞋子多余生产，不得不降价出售。
下面还有一些近年大公司更大的系统开发失败的例子。
Company Year Outcome
Hudson Bay (Canada) 2005 Inventory system problems lead to $33.3 million loss.
UK Inland Revenue 2004/5 $3.45 billion tax-credit overpayment caused by software errors.
Avis Europe PLC (UK) 2004 Enterprise resource planning (ERP) system cancelled after $54.5 million spent.
Ford Motor Co. 2004 Purchasing system abandoned after deployment costing approximately $400 M
Hewlett-Packard Co. 2004 ERP system problems contribute to $160 million loss.
AT&T Wireless 2004 Customer relations management system upgrade problems lead to $100M loss
所以，系统开发与设计的方法，其主要目的就是希望通过企业界的培训也好，对于商学院和计算机系的学生开课也好，目的只有一个，就是希望将来他们在遇到系统开发与设计的时候，可以在参与SAD开发的项目的时候，避免错误，力保成功，当然，这个假定就是，系统开发与设计这种方法，是可以学习的，经过不断的学习，不断总结经验教训，是可以避免的。也许Standish公司的调查说明了这个问题吧，1994年开始的Chaos report，到2009年，系统开发的成功率已经由16%上升到32%，即便近几年来有些起伏。
这个帖子我会一直写下去，因为最近就在教这门课，很希望通过写这个帖子，将知识理一遍，跟这里有实践经验的朋友交流。
续
元宝推荐：铁手, 通宝推：邓侃,
本帖一共被 1 帖 引用 (帖内工具实现)家园 感觉现阶段的系统开发像是门艺术，标准还没建立 当然永远会有新行业新需求，不过学成熟的行业，开发也越容易，当然也就死掉太多的竞争失败者
家园 有点这感觉吧 有人说，系统开发80年代之前，都是泥瓦匠的水平，之后开始有建筑师了，方法还在不断发展。
家园 作为课程，把SAD方法学教给学生就可以了 兄作为教师，如果能够把SAD的系统化思考方法教给学生就是功德无量了。所谓师傅领进门修行在个人，兄不会指望课程下来，兄的学生个个都成为合格的系统工程师吧？这是不可能的，有些东西靠的是个人积累，教不了的:-)
俺以为一个合格的软件系统设计师需要三方面知识。
1、系统工程方法学知识。
2、应用领域知识。
3、软件开发领域的知识。
从俺的个人体验来看，新鲜出炉的毕业生和部分工作了几年的工程师，最缺的就是系统工程方法学的训练。
举个例子，俺最近在做一个人民水师的项目，团队里面的工程师其实2、3方面都不差，可是这项目始终是一团混乱没有进展的状态，老板急了，交不了东西要被水师打屁屁的，所以付钱给外面的人（俺）来弄这个项目。俺去了之后发现，因为团队成员缺乏系统工程方法学方面的训练，前一段时间做了很多无用功，另一个直接后果是团队之间的工作配合也有问题。没办法，俺除了做这个系统的架构设计，还得额外花时间给团队做系统工程方面的基本培训，不然的话这团队俺也带不了。搞得俺很不爽，和老板说这个俺得额外收费。所以俺就想，如果团队成员在学校里面或者是前几年的工作受过系统工程方法基本训练，这项目完全用不着俺（水师的这个项目其实整体技术难度不高，架构设计上有两个难点，但也不算是高难度的技术活）。
最后，佩服一下兄的敬业精神，如今愿意花心思让学生学到东西的教师越来越少了。
家园 被淡化处理的需求管理和被强化宣传的新概念 简单说几句，供参考：
1.软件开发的本质是工程，即砌砖块和怎么砌，砌成什么样。（特点：砖块是抽象的，砖块的种类很多很多，砖块的特性使用说明，部分公开、部分不公开，还是洋文多）
2.砌成什么样，关键在设计，设计的关键在需求。
3.需求的关键在于业主的真正想法。有时真正的想法是不好直接说的，起码不是公开的说。微软会告诉大家，一些平直的流程，要搞成这样是为了隐藏要害，减低可能的竞争威胁，或者暗藏后门？ 一些不必要的抽象，是为了控制准入门槛？ 一些貌似精美、本质无太大变化的更新，是竞争策略，防止稳定系统上产生出强大的竞争对手。 用新概念、新工具的诱惑，让人们疲于追赶最新最亮丽的“应用级”技术后，对微软核心的挑战就会轻微太多了。
近年来看的越发清楚了，IT领域的忽悠也是大大滴。
家园 很有意思的说法 谢谢你的意见，太有意思了。
家园 理论与现实是有差距的 我做网络游戏已经有好几年，成功的产品也就一个，不过也是最成功的那个。最近又翻看起一本网络游戏开发的书，书中的观点有些同意，有些不同意。比如书中说，开发一个游戏要好几年。我就非常不同意这个观点。如果要好几年的话，黄花菜都凉了。我们开发一个游戏的周期一般是一年、两年，如果一个游戏开发几年的话，这个游戏要不就非常成功，要不是肯定失败。失败的例子见到多了。好像有点跑题，哈哈。
家园 暴雪不就挺成功吗，全部好几年再跳票几年，当然这是特例。 家园 你都说这是特例了 这要看团队的。如果一个团队很强，它确实在做一件很正确的事情，那么时间长一点也没问题。但是这是风险很大的。举个简单的例子，电影阿凡达（不明白为什么叫阿凡达这个名字，游戏行业中这个译音一直都说阿瓦挞，或者干脆就是意译纸娃娃），我认为，如果不是导演做出了3D的版本，那么他这12年的努力就肯定不能取得现在这样的票房佳绩，从2D电影来看，它不比其他的电影有多突出，真是3D的场面震撼了大众。游戏也是这样。现在软件的技术发展得很快。如果1个游戏在4、5年前就开始开发，那就要有很大的前瞻性，要预计4、5年后硬件的发展水平到什么程度，软件的水平可能会到达什么高度。也许一些技术在4、5年前是比较难实现的，但是几年后这个技术说不定在游戏学院(对不起我歧视游戏学院了，但是我觉得如果想要入行游戏，千万不要浪费钱去上什么游戏学院）的学生就可以轻轻松松实现了。那是不是很吐血的事情呢？