软件方法读后感10篇

　　《软件方法》是一本由潘加宇著作，清华大学出版社出版的平装图书，本书定价：58.00，页数：264，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

　　《软件方法》读后感(一)：如何用UML来做需求分析

在面向对象的需求分析方法中，UML的地位是不容动摇的。
在和很多做产品做需求的小伙伴聊过后发现大家对UML的了解非常的少，在之前组织的需求分析实战中也发现了这一点。
反而对程序员GG来说，UML的普及率会更高一些。
有的人会说，我不用UML，需求分析的也挺好的啊，产品做的也没什么问题啊。
如果你正面临着下面这些问题，我建议你看一下这篇文，并且学习并应用UML。
- 我对自己的产品功能了如指掌，但是却无法总结出所有的系统角色特征
- 测试写的用例我提不出意见，但是测试结束后我却经常发现之前没有想到过的用例
- 在做原型及需求文档时，有时候会遗漏某个功能或者场景
- 与程序猿经常无法沟通，我觉得自己写的文档、画的原型已经很清晰了，但是他们就是看不懂
- 我完全不知道产品中的业务主流程在执行的过程中会有哪些对象参与
什么是UML？
统一建模语言（UML，UnifiedModelingLanguage）是面向对象软件的标准化建模语言。UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。在软件无线电系统的开发过程中，统一建模语言可以在整个设计周期中使用，帮助设计者缩短设计时间，减少改进的成本，使软硬件分割最优。
简而言之就是一种语言，一种规范。就好像音乐用五线谱、简谱表达，数学用公式表达，需求模型用UML来表达。曾经有的人希望在需求阶段将UML做的很规范，并可以由此直接生成代码。就像现在的原型可以直接生成页面代码一样。现在已经有很多工具可以做到这些了，虽然生成的代码不是那么的让人满意。但是不排除未来掌握UML和业务的人员直接跳过程序员编写软件产品。
UML带给需求分析什么？
以小婧使用UML的经验来看，UML会给需求分析及需求相关人员提供更清晰、明确的目标。
我经常说，用UML重点是要充分应用它面向对象的分析方法。也就是在做业务分析的时候，将信息抽象成对象进行分析，可以使得自己避开“干扰”信息，抓住“主线”。
你会对你的解决方案更加有信心，知道哪些地方存在改善的空间，会给用户带来什么价值。如果发生需求变更，你也会很清晰的识别出影响点。
你设计出来的产品和业务流程会更加连贯、合理、有逻辑性，模块及功能之间的耦合关联也非常清晰。就好像你看蜘蛛网仿佛毫无章法，但是仔细看来却是一件完美的艺术品。
UML适用于哪些阶段？
而我们从UML的定义也可以看出，UML主要是服务于设计的。在需求分析阶段，我们如果能很好的使用UML，将会为代码设计提供很好的支持。
UMLChina在《软件方法》一书中提出了一个概念叫核心工作流。使用核心工作流可实现“低成本制造好卖的产品”。
1 业务建模——组织要解决什么问题
做产品需求的人都知道，我们需要去找甲方的痛点也就是问题，如果我们的产品可以很好的解决问题，那么人家就愿意付钱，我们就能盈利。
而你的产品能带给用户什么价值，这个价值到底是否足够大到吸引用户来付费。你可以通过业务建模来进行分析。要知道引进一个软件系统，和招聘一名新员工没有本质的区别。我以前经常会被challenge的问题是：我为什么要买你们的系统，我用Excel也管的挺好的。
业务建模阶段思考的焦点是：组织内系统之间
推荐UML元素：用例图、类图、序列图
2需求——为了解决组织的问题，待开发系统应该提供什么功能和性能
这里强迫我们从“卖”的角度思考哪些是干系人在意的，哪些不是。
需求阶段思考的焦点是：系统边界
推荐的UML元素：用例图、文本
3分析——为了提供功能，系统内部应该有什么样的核心机制
在用户的整个业务流程中，你的产品是在哪个部分起什么作用的。大部分的软件产品的作用就是取代人工，实现自动化。以前我们去餐馆点菜需要服务员拿个小单子来写你点了哪些菜，或者直接人脑记忆；付款的时候，老板要收集小单子或者记录在小本子上，以便休息的时候计算营业额。但是现在我们去吃饭，直接一个IPAD，菜单、点菜、消费记录全部自动化。装在IPAD里的系统是通过分析得到的。
在分解阶段思考的焦点是：系统内核心域
推荐的UML元素：类图、序列图、状态机图
4设计——试了提供性能，系统的核心机制如何选定技术实现
主要聚焦：系统内各域之间
UML：不画，代码即设计
从上面几个阶段我们可以看出，对于我们产品需求人员需要掌握的UML其实只有那么几种：用例图、序列图、类图、状态图。
有人会问，为什么没有活动图（流程图）？我觉得如果你和用户或者业务人员沟通，可以使用活动图、但是如果你是为研发、设计服务，建议使用序列图。因为序列图会强迫你去思考所有的动作背后的目的。
【图】
关于各种图的具体画法我觉得大家去问度娘会得到比我这有限篇幅更详细的信息。而针对用例图，我最近看到一种说法，觉得很有意思，在本文中做一个分享。
潘加宇老师在《软件方法》中提到了两种用例图：业务用例图和系统用例图。
之前有小伙伴说，测试和开发看不懂他画的用例图，很苦恼。我仔细看了下，确实是有些表述不清。因为他把业务用例图和系统用例图弄在一起了。
业务用例图
业务用例图主要是用在业务建模的阶段，目的是从甲方的角度来定位系统应该提供的价值。所以业务用例图研究的对象是甲方组织。甲方的组织里面包括哪些角色，哪些软件系统，哪些部门？而我们的系统将承担这些对象中的哪些对象的大部分职责？
另外一方面，业务用例图的Actor执行者是业务执行者，即组织外与组织交互的人群或组织。比如你的甲方是某商业银行，其Actor是储户、企业用户、人民银行。研究的是他们将会与商业银行产品什么用例。
系统用例图
系统用例图主要使用在需求阶段，我们其实最常用的是系统用例图。系统用例图的主要研究对象是系统，也就是我们待开发的软件系统。
系统用例图的执行者是在系统外与系统发生功能性交互的其他系统。所以重点在于这个执行者与系统发生功能性交互。比如前些日子小婧的身份证过期了去办身份证（我又暴露年龄了）。身份证办理系统的执行者包括：办证人员、数码相机、指纹采集仪。这里要注意的是我并不是系统的执行者，至少在这个非自助的系统中，我不是。
---
写在最后
在实际的产品需求分析过程中使用UML，不论对你的产品还是你自己而言都会收益颇多。
但是和所有的方法一样，在学习和实践一种新的方法时会面临很多的挑战，也会有很多的问题。
单纯就从UML的角度来说，我觉得有这样几个方法可以来学习实践：
- 对自己产品进行梳理，尝试用UML的用例图、序列图（时序图）绘制现有系统业务，并与开发人员讨论。通常来说，开发对UML的了解会更深入，这可能是和现在常见的开发语言，比如C系列、Java等也是面向对象的语言有关。
- 度娘UML的绘制方法。现在很多文章和博客都介绍的很详细。
- 通过阅读一些比较经典的UML书籍。
- 欢迎和小婧进行沟通交流。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！

　　《软件方法》读后感(二)：一流的书

也许是因为我已经有多年的经验，我认为此书超过我过去看过的任何一本讲具体软件过程方法的书。
无论如何，我认为做过二、三年软件开发的程序员，应该人手一册此书。更不用说，从事产品设计、业务/需求分析，软件项目经理，将软件“愿景”落实到可编码开发阶段的人。
特别推荐，如果你专门从事项目研发、信息化建设，此书你应该好好看上三五遍。
从来没有像这样推荐过一本书，作者以精湛的“建模”技术、方法、经验，向我们展示了软件开发活动中的重要、核心环节，以系统、独特、有趣、还能跟“互联网”结合的视角将这些环节一一解剖。我认为这本书就是“正统”的武功，像“降龙十八掌”，“九阳神功”之类。
作者以多年的培训指导经验出发，除了文字以外，在每一章、节之处，都附有有趣的“思考题”，让读者加深印象，锻炼思考，实是作者用心良苦啊。
话说，我跟作者没有半毛关系，我是偶然在寻找UML建模工具时，在UMLCHINA上看到的此书推荐，我想，既是UMLCHINA推荐，买来看看吧，曾经我也是UMLCHINA的“匿名用户”，支持一下他们老大吧。想不到，买了之后如此喜欢。
我还没看完，看完也许还有补充。

　　《软件方法》读后感(三)：我们这些码农

《软件方法上-业务建模和需求》
如何做好一个软件？
一个软件要做的工作可以量化么？如果能量化，那有流程么？如果有流程，那有方法么？
大学学的是计算机，但是最不愿从事的行业就是软件。结果呢，出了校门现在，一干就是8年。我并不是在摆什么资质，因为我们应该清楚，一份工作你重复干了8年，你的经验并不是8年，而是一年而已。
《软件方法》讲的是用UML语言来辅助我们进行软件的从0到1的过程。这个过程的结果并不是最终运行在电脑屏幕上的那个界面，而是一堆图纸，可视化的图纸。
是的，确实是图纸。建筑行业有设计和施工图纸，电工行业有设计和实施图纸，城市规划有图纸··· ···任何你看得到的工程都有图纸，你要写的软件居然没有。
“图纸在我脑子里呢”，我也曾经说过。直到看到这本书。
这本书的直接受众应该有两类人：
1.程序员
这类人一般的工作思路就是提功能的人说要做什么，嗯嗯哦哦之后，迫不及待的打开编辑器开始写代码，调试，然后发现做完的东西，总是被告知要修改，没玩没了的改。
2.项目管理者
这类我们称之为“IT包工头”，他们既要跟客户聊需求，转头还要跟程序员转述。作为一个中间人，两边都要沟通，现实是两边都没沟通好。用户说的不就是这样的么？怎么做出来的东西就是不对呢！面对需求和变更，他们是最无奈的，因为他们面对的并不只是程序，而是公司的成本和效益。
我甚至推荐产品经理也来看看这本书，因为一个产品到底要满足谁的需求，提供什么样的功能是一开始就要想清楚的事情。精益思想的逐步迭代改进是没错，但是也要求你在产品之初，能想明白你产品到底能带来什么样实实在在的客户价值。
很庆幸能在工作的第8个年能看到这本书，更荣幸的是，和自己的团队在一起用了7个课时一起讨论学习，一起做作业。最让人兴奋的，是每一次在进行项目讨论的时候，我们都开始用《软件方法》中学到的知识，用新的方法在做我们每天都该去的的事情：内部沟通更加有条理了；需求变更更加谨慎了，和客户的沟通更加有效率了··· ···
这是不只是一本书的作用，更是不断打破自己习以为常的工作方式的决心。
希望大家一起加油！

　　《软件方法》读后感(四)：UML中国业余首席专家的名作

读完潘老师的这本大作，我的总体印象是：
概念不清，用词不当，东拉西扯，逻辑错乱。
全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有：
- 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）；
- 全书对于“涉众”（Stakeholder）这个基本术语的理解几乎通篇是错误的，而且前后矛盾；
- UML 模型不是用来和涉众沟通的！（很难相信这是一位 UML 首席专家的言论）；
- 涉众没有资格、也没有责任提供需求；
- 把 Actor 译成“执行者”，导致许多违反中文常识的语病，如：人民银行是商业银行的执行者，患者是医院的执行者；
- 系统 Actor 和重要无关，和重要有关的概念是涉众；
- 观众（涉众）在台下看，Actor 在台上表演（其实呢，台上的演员也是涉众）；
- 需求或用例的“粒度”、“层次”这些概念其实并不存在，对开发人员的误导相当严重；
- 设计就是代码，所以设计工作流不推荐画 UML 图；
- 界面组件不是需求。人有眼睛不是需求；
- 只用两三章介绍了 UML 的用例图和业务序列图，未强调业务活动图，也未详细介绍 UML 需求分析中常用到的其他图形，如系统序列图、活动图、状态图等（内容单薄、片面）；
- 第 2 章所谓的“愿景”，只是区区几个“老大”或涉众的目标，名曰“度量指标”，却连一个数量也没有说明，实质内容与愿景文档差距甚远；
- 作为需求分析的名著，从第 3 章到第 6 章的重点章节只介绍了以用例为主的动态建模，未详细介绍需求分析的另一半——静态建模（如领域建模、概念建模）；
...
基于以上这些错误和缺陷，我给全书的评价是将将及格，只达到了业余研究 UML、需求分析的中等水平，潘老师作为 UML 中国业余的首席专家名至实归，恭喜恭喜！
UMLGreatChina 首席专家、创始人 张恂 ;-)