导图社区 学校没教的软件工程课
在软件开发领域，数大，便是难，软件开发的复杂导致很多议题在学校的课程上无法得到呈现，作者通过以往的软件工程案例总结了30个要点，来帮助软件相关人士感受软件工程的挑战以及重要性，同时帮助大家避免不必要的开发误区
《半小时漫画青春期》是一本适合青少年阅读的科普读物，它以幽默风趣的漫画形式，深入浅出地讲解了青春期的各种烦恼及其背后的原理，帮助青少年正确认识和理解青春期的变化，减少困惑和烦恼，顺利度过这个特殊的人生阶段。
现如今，不确定性慢慢变成了常态，⽽不是意外。你有你的计划，世界另有计划，要适应这个即兴时代，就要掌握即兴表达的能⼒，我们都要做好准备：招之即来、来之能战、战之能胜、挥之即去。
你是不是有这样的困惑，电脑越用越卡，但是又不知从何下手去清理，小编整理了一些清理C盘的技巧，赶紧用来试试，帮你的电脑瘦瘦身吧
社区模板帮助中心，点此进入>>
浏览器中输入URL后发生了什么？
软件项目阶段文档
ASP.NET Core 应用开发
IT软件开发技术必备的网站大全
一挚物联
软件设计师
软件需求分析工作
web开发管理
软件开发
新航海APP开发
学校没教的软件工程课
开发进行前
第一式:需求不简单
需求不能只听客户的表象描述，必须进一步诱导客户往下深谈，才能正确了解需求
一般而言，期望客户明确定义需求，并不切实际。因为有些需求，实在难以表达清楚，有些需求， 客户当下甚至没有考虑到。
软件开发的复杂度和需求，不一定是等比的倍数关系。有时候需求越多，软件开发会变得越困难
第二式:需求不仅是功能
开发需求时，除了功能需求外，还要考虑其他议题，如：效能，网络限制、安全等非功能面的需求
非功能需求通常会影响软件设计的考虑
以建筑设计为例，房子的功能需求可能类似，但是建在海边和市区的结构需求则显然不同
应用场景不同，侧重点不同
非功能需求不能只是形容词，应该将之量化
例如：若只说执行时响应快，这就是形容词，应该要量化说明时间，譬如20个并发用户下，平均响应时间为1秒
第三式:领域知识
开发需求时，通常会涉及专业的"领域知识"
欠缺相关领域知识，定义需求有时会有困难，同时需求也容易被误解
领域知识除专业学习外，在该领域参与实际工作所积累的经验，对需求发展相当重要
第四式:可读性
当需求转化成文档后，文档本身的可阅读性，会影响对需求的理解和认知
需求文档毕竟不等同于需求，因此文档的撰写仍可能会造成需求上的差异
落实文档标准化，可以减少但不见得能够完全避免对需求的误解
第五式:变是常量
需求会随时间推移而改变，这是软件开发团队必须认知且无法避免的现象
尽管需求会随时间推移而改变，但整体而言，应该逐步收敛而非越来越发散
要避免需求越来越发散，应尽可能先建立应用全貌
例如：对企业领域而言，可发展企业架构
软件开发必须控制在预计时间内。否则拖的越久，改变可能就越多
做好需求管理，避免需求变更所可能造成的影响，是面对此问题的关键工作
第六式:文档不可少
软件开发过程的无形性【即看不见，摸不着的特性】，常常是事先撰写文档的问难
许多软件开发团队是在程序完成后，才回溯撰写相关文档，甚至没有文档
软件开发事先没有相关的设计文档，就像造房子没有设计图一样，不可思议
第七式:软件架构知识
软件开发不是依靠程序高手，遵守规范，配合程序的系统化思维更重要
软件开发就像盖房子一样，应有一定的设计原则与方法，不同的设计原则与方法，是为了满足不同的软件需求
好的软件设计必须具备"软件架构知识",才能确保满足非功能需求或其他与质量、维护等相关目标
软件架构知识可以通过学习已知的软件架构设计样式而获得
第八式:应用知识
具备领域相关知识，虽然对需求确认相当重要，却无法仅靠领域知识，就可将需求转化成可被拿来应用的软件系统
当需求确认后，经过系统分析产出软件的系统架构。不同的分析结果，势必产出不同的系统，分析越好的系统，才越能满足应用目标，而分析能力则与“应用知识”相关
应用知识虽然可以经由学习获得，但通过长期接触同领域内的类似软件，并积累其应用经验才更有价值
第九式:用户体验
软件除应考虑用户操作习惯外，同时也应将使用环境的影响纳入设计考虑，换而言之，软件设计绝对不能忽略"用户体验"
具备良好用户体验的软件，除可提高用户的使用效率与满意度外，也可降低开发团队以后对使用者的维护成本
好软件一定要考虑界面的【优使性】设计
第十式:做对？做好？
"做对软件"是指开发完成的软件，其功能完全符合需求，同时执行的结果也完全正确
"做好软件"是指开发完成的软件，执行时不会不稳定，也不会因质量不佳而时常当掉
以需求为制作一张四只脚的圆桌为例
完成的桌子不是圆桌而是方桌，这是没有"做对"
完成的桌子虽然是四只脚的圆桌，但四只脚长短不一，这是没有"做好"
第十一式:开发软件不简单
"做对"和"做好"软件的四大关键
第1项：定义出正确的需求
第2项：将需求分析成系统
此两项不正确，开发团队不可能"做对"软件
第3项：发展用户界面设计
第4项：设计符合功能与非功能需求的软件架构
此两项没仔细投入设计，开发团队则不可能"做好"软件
此步骤需要在撰写程序之前完成
领域知识与应用知识有助于"做对"第1项与第2项工作，用户体验设计知识有助于"做好"第3项和第4项设计，而软件架构知识则有助于"做好"第4项工作
第十二式:雏形不靠谱
软件雏形是指在软件开发完成前，事先制作用来作为参考用的软件
为何需要雏形？一般的认知是因为软件在未完成开发前，即看不见也摸不着。雏形则可以让无形的分析设计，变成看得见又可实验操作的有形对象
不明就里的人，很容易以为雏形继续往下做就可以完成软件，殊不知就像建筑设计的雏形一样，不可能继续往下做就可以盖好房子
事实上软件雏形最重要的目的，是在面对特殊需求的挑战，例如：特殊非功能需求，界面设计问题，关键的功能需求等，由于存在疑虑，因此先做雏形以帮助探讨问题，进而解决挑战
软件雏形应该用完就丢，一如其他领域的雏形一样
第十三式:不只是写程序
软件开发不只是写程序，还涉及多项不同开发工作与步骤，因此过程管理非常重要，这个过程称为"软件流程"
一般产品的生产制作过程也有流程，称为制作流程，由于其步骤是一步步往前推进，因此也可称为"瀑布流程"
最简单的软件流程即为瀑布流程，其缺点主要是不够敏捷，因此许多过程中的产出，常常要等到写完程序后才看得到
软件开发要有流程步骤，不只是写程序而已
第十四式:敏捷不容易
在快速、短周期的多次反复程序下，透过每次的软件实作产出，敏捷的软件开发流程可以避免瀑布流程的缺点
敏捷的软件开发过程，通常需要经过多次反复进行，在此叠加过程中，可能因为新需求而需要重构之前的软件架构设计，叠加过程中，也需要不断持续集成测试，确保之前与本次开发的一致与正确
当软件的需求少或简单，选用任何一种软件开发流程都没有问题，当软件的需求多且复杂，选用任何一种软件开发流程都有问题
敏捷可不是什么都不要，或不在乎
第十五式:预估跑不掉
软件开发不像一般产品生产，原物料与加工人力工时明确，反而因为过程中存在太多的无形与不确定性，所以估算开发成本相对困难
尽管软件开发成本的预估有其难度，但是若不做预估，则无法展开项目规划与管理，因此，预估是软件开发跑不掉的事
开发进行中
第十六式:牵一发动全身
软件设计时，架构上应该要支持扩增性，特别在面对需求时常变动的用户时
软件设计时，架构上也应该尽可能松耦合，亦即当需要改动软件设计时，不会如涟漪一般向外扩散
第十七式:昨天永远是对的
软件交付到客户手上前，一定要经过测试把关，以确保软件符合需求，同时没有错误
软件开发在不同阶段，各有不同的对应测试，例如：个别程序开发时，应该进行个别程序的单元测试或功能测试，但是，到了多个程序集成在一起时，就需要进行集成测试，甚至与非功能目标有关的测试，例如：压力测试或是效能测试等
功能测试正确，并不代表集成测试会正确，反之亦然
第十八式:改A错B
质量是软件成功与否的关键，没有好质量，就不会有好软件
检验软件质量的最重要手段在于测试，其中包含各类不同目的的测试
当软件版本更新时，不应该只测试有变动的部分，而是要从头到尾全部再测试一次，这正是"回归测试"的重要目的
第十九式:质量不是测出来的
测试并不能改善质量，只能帮助检验质量水平，真正质量的改善，还是得回归到软件设计与程序撰写
若等到最终软件完成后才进行测试，万一质量无法过关，此时要再改善也不容易，因为这涉及太多的知识环节，更不能像一般产品，抛弃瑕疵零件重新制作
为确保质量，一定要好好落实软件的开发步骤，并维持每个步骤该有的审核、测试与检验。质量究竟是做出来，而非测出来的
第二十式:软件的生命
软件从开发、上线使用、到最后退役换新，过程中就像照看一个小孩，一路从小到大，到老。软件也会生病(bug)、也会改变(新需求)、也会长大(版本更新)、也需要适应新环境(新一代的操作系统或是数据库)
照顾维护软件一生的过程称为"软件生命周期管理"
大部分的客户通常指关注软件当下的满足度，常常忽略软件生命周期管理的重要性
软件开发团队更是常常忽略软件生命周期管理的挑战
第二十一式:一部历史
在软件生命周期中，随着时间的推移，许多变更(包括需求、设计、程序本身等)必然发生。这些变更经年累月，若没有很好的记录、追踪与管理，届时就可能像挖马路、不小心会挖到不该挖的管线，进而造成灾难
为了避免上述问题，软件的版本控制很重要，"构建管理"或者就是软件生命周期中一定要执行的工作
第二十二式:换人
软件生命周期中，软件开发与维护团队的人员变动不可避免，即使人员无变动，软件的同一个程序，也不可能都由同一个人维护，当然，若是小软件，少版本，小团队，则可能例外
当软件的不同客户有不能需求，就需要为了这些客户客制修改程序，软件构建管理自也应纳入这些客制需求的管理，每当软件版本变动时，构建管理应该自动提示每个客户客制需求的跟版检查，如此才能避免因版本变更而造成客制功能的消失
第二十三式:加人
软件生命周期是一件涉及需求、设计与程序开发等不同知识的工作，与传统的产品生产或房屋建筑等过程不同，因此，新进的人力往往需要花费许多时间理解前述知识，才能逐步投入工作
当更多的人投入软件开发过程中，由于涉及对上述各种知识认知的落差，新旧成员间的沟通成本将大幅增加，因此期初的生产力通常不增反减。若此类沟通协作问题长期仍无法有效解决，将可能造成软件开发的延滞甚至最终失败
第二十四式:试错勿慢
软件开发过程中大部分的产出，一般用户大多无法理解，只有完成的软件部分，一般用户才能认同有所进展。因此，程序开发时的"宁错勿慢"便成为许多软件开发团队的魔咒
软件毕竟与其他产品产出或房屋建筑不同，事后修改错误所花费的时间与人力成本，通常会得不偿失，甚至造成软件最终以失败收场
赶进度写程序，有错误以后再说，这正是许多软件失败的原因
开发完毕后
第二十五式:到底了没？
软件生命周期中，特别是较大型或是复杂的软件，用户有时候会碰到不可预期的异常现象，除程序错误外，有些事需求变更，有些则是因为系统环境改变所造成，但有些异常则很难判决。通常软件开发团队负有解决上述异常的责任
软件生命周期中，多家用户，多种异常的出现，史书不可避免，假如没有追踪管理这些异常或由其所衍生的相关议题，软件质量与服务最终将不可信赖
第二十六式:生产力
对比其他行业的生产程序，其生产力相对容易量化计算，也可以相对客观反映工作人员的贡献程度
软件开发属于知识工作，软件生产力的计算相对困难。软件生产力除最基本的程序代码产出外，尚应考虑质量、难易程度，与过往经验(可以直接复制)等，不一而足
上述相关因素，有些甚至无法当下呈现，例如：质量。若无完善的测试程序，许多错误可能要等到被用户使用时才能发现，但当下生产力的计算却无法顾及
软件生产力最常被误算
第二十七式:就是要管理
尽管软件开发是抽象的知识工作，但并非无法管理
尽管软件开发流程可被标准化，但若无法落实执行，管理则无从实现
软件开发项目管理议题中最被关注的，不外乎是成本，进度和质量。其他如生产力或瑕疵密度等，则是依前述三个议题所展开的检测指标。例如：生产力显然与成本、进度相关，而瑕疵密度则与质量有关
如何建立量化指针与量测程序，是发展软件项目管理的重要工作
软件开发，就一定要接受管理
第二十八式:集成躲不掉
大部分企业或政府等组织使用的软件，最终势必面临集成。这些组织型单位，不可能只靠一个软件就可满足所有需求，而不同软件间却又必须合作
软件集成涉及多层不同的议题，包括从数据面，流程面，应用功能面、到前端界面等，同时还需考虑同步与否与一致性保障等，因此非常复杂
尽管目前集成中间件技术成熟，集成程序的开发并不困难，但集成最大的挑战主要来自对集成知识的不足，集成知识除需具备应用知识外，更必须熟悉各个集成机制以及其运用时的各种可能影响
集成永远是可怕的挑战
第二十九式:没有好不好，只有用不用
软件开发完成后，用户是否愿意使用该软件，才是最后成败的挑战
软件从应用分析到用户体验的设计，想要满足各色不同背景的使用者，本来就不容易，特别是复杂的软件
与其责怪软件设计不佳或不能满足预先期望，不如先通过训练，推动用户学会并使用软件。让软件发挥初步作用后，再来谈可能的改善，帮助软件在其生命周期中成长茁壮
再难用的软件，只要愿意用就可以发挥作用，而可以发挥作用的软件就是算是好的软件
软件是可以发挥用处的就是好软件
第三十式:人的工程
软件要成功，就一定得会软件工程
句子摘抄
在软件领域，数大，便是难，软件开发的复杂度，往往随着需求的增加而成指数增长
原因一：在于需求的无形性【IKIWISI：等我看见才能知道】
原因二：软件需要多人长期合作(软件开发需要众人合作，软件越成功，软件的生命周期越长)
周忠信
