作者：周忠信
出版社：化学工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
学校没教的软件工程课试读：
前言
徐志摩的散文里说道“数大，便是美”，但在软件领域里却是“数大，便是难”。
软件开发的复杂度，往往随着需求的增加而成指数增长。其关键原因，首先在于软件需求的无形性（intangibility），而这也正是软件领域著名的南加州大学教授Boehm博士所提出的IKIWISI（I'll Know It When I See It）现象——等我看见才能知道。换言之，许多人必须等软件编程后，才能确定是否满足需求。 因此当需求越多，往往会牵一发而动全身而越难修改。另一方面，当软件越庞大，软件开发越需要众人合作；而软件越成功，软件生命周期则会越长。这种需要多人长期合作的工作，若没有一套工程化的程序与管理办法，软件最终势必走向失败。
上述这些议题很难在课堂上显现，因为一般的课程时间比较短，软件生命周期问题很难显现，同时大学课堂也很难接触真正的大型软件开发。因此，在学习软件工程时，实在难搔到软件开发的痒处。为了帮助大家更能体会软件工程的挑战，本书整理了过往30个软件工程案例，并以漫画形式呈现。希望可以帮助所有软件相关人员体会软件工程的重要，同时更能避开软件开发误区从而走向成功。周忠信第1式需求不简单●需求不能只听客户的表象描述，必须进一步诱导客户往下深谈，才能正确了解需求！●一般而言，期望客户明确定义需求，并不切实际。因为有些需求，实在难以表达清楚；有些需求，客户当下甚至没有考虑到。●软件开发的复杂度与需求，不一定是等比的倍数关系。有时候需求越多，软件开发会变得越困难。第2式需求不仅是功能●开发需求时，除了功能需求外，还要考虑其他议题，如：效能、网络限制、安全等非功能面的需求！●非功能需求通常会影响软件设计的考虑。以建筑设计为例，房子的功能需求可能类似，但是盖在海边或是市区的结构需求则显然不同。●非功能需求不能只是形容词，应该要将之量化。例如：若只说执行时响应要快，这就是形容词，应该要量化说明响应时间，譬如说，在20个并发用户下，平均响应时间为一秒。第3式领域知识●开发需求时，通常会涉及专业的“领域知识”（domain knowledge）。●欠缺相关领域知识，定义需求有时会有困难，同时需求也容易被误解。●领域知识除专业学习外，在该领域参与实际工作所累积的经验，对需求发展相当重要。第4式可读性●当需求转化成文档后，文档本身的可阅读性，会影响对需求的理解与认知。●需求文档毕竟不等同于需求，因此文档的撰写仍可能会造成需求上的差异。●落实文档标准化，可以减少但不见得能完全避免对需求的误解。第5式变是常态●需求会随时间推移而改变，这是软件开发团队必须认知且无法避免的现象。●尽管需求会随时间推移而改变，但整体而言，应该逐步收敛而非越来越发散。●要避免需求越来越发散，应尽可能先建立应用全貌。例如：对企业领域而言，可发展企业架构（enterprise architecture）。●软件开发必须控制在预计时间内。否则拖得越久，改变可能就越多。●做好需求管理，避免需求变更所可能造成的影响，是面对此问题的关键工作。第6式文档不可少●软件开发过程的无形性（intangible），亦即看不见、摸不着的特性，常常是事先撰写文档的困难。●许多软件开发团队是在程序完成后，才回溯撰写相关文档，甚至没有文档。●软件开发事先没有相关的设计文档，就像造桥盖房子没有设计图一样，不可思议。第7式软件架构知识●软件开发不是依靠程序高手。遵守规范、配合程序的系统化思维更重要。●软件开发就像盖房子一样，应有一定的设计原则与方法。不同的设计原则与方法、是为了满足不同的软件需求。
试读结束[说明：试读内容隐藏了图片]