2023年《班主任工作的系统方法》读后感.docx

班主任工作的系统方法读后感 浅谈系统分析与设计方法 系统分析与设计方法，顾名思义，是论述软件开发过程中涉及到的分析与设计过程的方法论。作者依照软件开发过程将书划分为四个局部：系统开发项目环境、系统分析方法、系统设计方法、系统分析和设计完成后的工作。同其他美国作者一样，作者通过一个贯穿全书的案例--音阶公司系统项目，向我们详细地讲解了开发一个软件系统过程中设计到的知识。 第一局部“系统开发项目环境〞介绍信息系统开发的概念和过程。第二局部“系统分析方法〞涵盖了生命周期前期活动、工具和技术，这些内容用于分析业务问题、说明信息系统业务需求以及制定业务和系统方案。第三局部“系统设计方法〞涵盖了生命周期中期活动、工具和技术，特别强调应用架构的概要设计和详细设计、快速开发和原型设计、外部设计（输出、输入和界面）、内部设计（如数据库和软件工程）以及面向对象设计。第四局部“系统分析和设计完成后的工作〞通过纵览生命周期后期活动，透视系统分析和设计工作。 读完这本，我不仅收获了如何进行系统分析与设计的指导思想，学会了uml工具等，更对一个软件系统的从需求分析到后期的运行、维护的整套工作流程有了一个概括的认识，了解了各阶段的需要撰写哪些文档，学会了如何与各种人员进行交流等待。但这本书给我启发最深的不是技术方面的知识，而是让我对软件工程有了一个更为深入、透彻的认识。 早在20世纪中期，计算机刚被参军用范畴转向民用范畴运用，那时编写程序的工作被视同为艺术家的创作。由于硬件资源的限制，编程人员追求的是如何在有限的处置器才能和存储器空间约束下，编写出执行速度快、体积小的程序，所有这时的软件开发十分依赖于开发人员的聪明才智。而到了20世纪60年代，计算机的应用范围得到较大扩展，对软件系统的需求和软件本身的复杂度急剧上升，传统的开发方法无法顺应用户在质量、效率等方面对软件的需求。这就是所谓的“软件危机〞。为了解决这个问题，便引入了“软件工程〞这一概念，从而开始了软件开发从“艺术〞和“个体行为〞向“工程〞和“群体协同工作〞的转化。何谓工程。百度百科中对这一词的解释中有这样一句：以最短的时间和精而少的人力做出高效、可靠且对人类有用的东西。于是，当“软件〞遇上“工程〞，软件开发就不再是几个人的单兵作战了，它需要所有人的齐心配合与人员的协调，用一套已验证的工作流程来共同完成一项任务。曾经，当我在大一学习编程语言的时候，我只是认为编程就是软件工程师的全部工作，只有拥有高超的技术才能在这个行业立足。现在再回头看，才发现自己的认识有多么的浅薄。系统分析与设计方法这本书围绕软件开发这一中心，详细讲解了从需求分析到后期维护各个阶段中，如何运用文档与周围的人员进行有效沟通和协作。文档，作为各类人员之间的桥梁和纽带，如使用得当，有以下几个好处： 1.提高软件开发过程的能见度。把开发过程中发生的事件以某种可阅读的形式记录在文档中。管理人员可把这些记载下来的材料作为检查软件开发进度和开发质量的依据，实现对软件开发的工程管理。 2.提高开发效率。软件文档的编制，使得开发人员对各个阶段的工作都进行周密思考、全盘权衡、从而减少返工。并且可在开发早期发现错误和不一致性，便于及时加以纠正。 3.作为开发人员在一定阶段的工作成果和结束标志。 4.记录开发过程中的有关信息，便于协调以后的软件、开发、使用和维护。 5.提供对软件的运行、维护和培训的有关信息，便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解。使软件开发活动更科学、更有成效。 6.便于潜在用户了解软件的功能、性能等各项指标，为他们选购符合自己需要的软件提供依据。 也正是基于这样的好处，软件行业才会定义、开发各种沟通表达工具和建模语言来统一沟通方法，从而便于各种人员的团结合作。以uml为例。从1989年到1994年，建模语言数 量从不到十种增加到了五十多种。90年代中，又一批新方法出现，其中最引人注目的是booch199 3、oose和omt-2等。但到目前为止，uml这一统一建模语言脱颖而出，它贯穿软件开发周期中的每一个阶段，并被omg采纳作为业界的标准。就如书中所讲，uml是一个标准的图形表示法，它不是面向对象的分析和设计，也不是一种方法，它仅仅是一组符号。uml是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。当模型建立之后，模型可以被uml工具转化成指定的程序语言代码。所以说，运用优秀的沟通工具与各种角色进行有效地沟通在一定程度上决定着系统能否保质保量的成功完成。在这个崇尚团结与合作的社会，作为新一代的软件开发人员，我们更应该认真学习书中说讲的各种文档编写方法，更好的运用到实际开发中去。 其次，这本书向我灌输的另外一个重要信息就是：沟通很重要，尤其是在获取需求阶段。书中详细阐述了七种调查研究技术：对现有文档、表和文件进行抽样；调研和实地访问；观察工作环境；调查表；面谈；获取原型；联合需求方案。通常情况，需求分析人员是计算机专家，而客户是业务专家，由于他们所从事工作的领域不一样以及个人的思维不一样，所以看待同一个问题的出发点也是不一样的，造成的结果是双方都以为讲的很清楚对方都理解了，结果根本不是这回事。通过这本书的详细讲解，我认识到需求获得是一项科学性的工作，需求的过程应当系统而又有方案地稳步推进。 首先，需求分析人员从接触到深入了解客户业务有一个渐进的过程，如果一开始就深入到业务的细节中去，不但容易迷失方向，而且很容易显露出你对业务的无知，客户会因此而失去与你沟通的兴趣。 其次，沟通双方都有自己习惯的沟通方式。所以在双方能够达成默契之前，不要急于深入业务细节，而是圈定范围，先就一些大框框进行沟通，借此了解客户的沟通方式。客户是喜欢开放型问题还是封闭型问题。客户是很健谈还是很含蓄。客户是主导型沟通者还是被动型沟通者。客户是具有很强逻辑思维的人，可以将一个问题有条不稳地讲清楚，还是一个发散型思维的人，总是没有什么目的地想到什么就讲什么。如果双方的沟通方式不能切合，必定会造成沟通的障碍。 再次，客户的时间是有限的，很多时候不能有整块的时间来配合需求调研。由于项目的周期也是有限的，因此每一次会面都需要争分夺秒，用最快的时间把问题搞清楚。另一方面，客户通常不会为需求调研做好准备，往往是等着答复以下问题的。如果需求分析人员寄希望于客户能有条不理的把一套业务都能讲解很清楚，整个业务形成闭环往往是很不现实的。这就要求需求分析人员根据经验提前要做好调研方案和内容，逐个进行落实。 最后，人都是善忘的，因此不要总是责怪客户朝令夕改。客户往往很容易忘记曾经说过什么，这是因为他不需要对需求调研的结果负责。如果需求分析人员也不肯承担起这个职责，将每一次的会谈结果记录下来，并有正式的反响和确认过程，那么到最后需求变更时，你将完全没有理由责备客户推翻他原来的需求。通常好的做法是循环逐步确认，每次调研的内容不易过多，每天的调研做好记录，做好界面，第二天再演示界面对需求进行确认，客户能直观的感觉到以后会是一个什么样子，再对提出的变更需求、遗忘需求和当天新模块调研的需求做以记录，并在第二天给与确认。 在通读了系统分析与设计方法这本书后，我对软件的开发过程在认识上有了质的飞跃，摒弃了浅薄的认识，站在一个更高的层次上看待软件工程，使我对自己的职业生涯有了进一步的规划。 第6页 共6页