个人读后感作业
用专业知识教育人是不够的。通过专业教育,他可以成为一种有用的机器,但是不能成为一个和谐发展的人。要使学生对价值有所理解并且产生热烈的感情,那是最基本的。他必须获得对美和道德上的善恶鲜明的辨别力。否则,他 —— 连同他的专业知识 —— 就更像一只受过很好训练的狗,而不像一个和谐发展的人。为了获得对别人和对集体的适当关系,他必须学习去了解人们的动机、他们的幻想和他们的疾苦。 ---- 爱因斯坦
学了一个学期的软件工程课,终于知道了个软件工程的大概。学的时候总觉得很抽象,理解起来好像不难,但总是摸不着头脑一种很茫然的感觉。学习的过程中和同学一起做项目,觉得还是有点收获的,对于开设这门课的意义也有所领悟。
曾经以为程序就是软件,软件就是程序。现在知道了二者的不同之处,这是学习这门课程第一个收获。事实上在软件开发的早期阶段这也不能说是错误的。那个时候开发的软件都比较简单。当然可以把软件理解成程序,直到软件作坊的出现,使软件在程序的基础上加了个说明。以前做过的一些小型的软件比如加密软件,我也只是在程序旁边附上一个软件的说明,看来已经很接近作坊了。不过大的项目没有接触过,用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生,使得人们不得不探索新的解决方法。
这个时候软件工程应运而生了。
我们为什么需要软件工程呢?上面已经给出了一些原因。专业点讲,软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计,没有设计指导的编程是无序的忙碌的。根据开发的软件的规模,应该适当程度的运用软件工程化的思想,需要灵活,毕竟我们开发的软件大多数是中小型的,大型的并不多见(我是这么认为的)。但只要涉及人员间的交流和沟通,或多或少都要需要软件工程才能更有效率,工作成果更稳定。
我们已经知道软件和程序是两个不同的概念,软件除了程序还要有使用和维护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、维护文档以及使用手册。
软件开发特别是大型软件是一项浩大的工程,需要几个人、十几个人、几十个人甚至几百个人合作开发几个月、十几个月甚至几年。要保证系统的协调性、统一性和连续性,就需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费一定的时间和精力,但是"磨刀不误砍柴功",它相当于把今后开发过程中开发人员都要遇到的问题提前做了一个考虑。有了开发规范,在后续的开发过程中,设计人员就不必每次考虑如何为一个字段命名,编程人员也不必去想某个程序的结构和布局应当 怎样,测试人员也有了判断程序对错的标准。开发规范在项目开发工作中起着事前约定的作用,需要所有开发人员共同遵守。它约束开发人员的行为和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契,以便形成整个系统的和谐步调和统一风格,也便于今后的系统维护和扩展工作。
在实际中开发软件首先应该考虑的是是否可行的问题。但在这个实习中其实根本没必要,既然已经选好了题目,而最终也不要求能够运行,钱、软硬件资源不成问题,当然可行。主要考虑的技术问题。
需求分析就是要确定自己要做什么,应该怎么做,心里有个底。需求是通过与用户充分交流和自己的创造力,去发明软件规格说明的过程。如果没有双方对需求进行分析,可能出现项目设计出来的东西或最终提交的可交付物根本就不是客户所需要的,或有相当的差距。所以用户和开发人员在需求上要达成一致性。在这个实习项目中只是给了几个要实现的功能。也没有真正的用户。凭大家的想象给出一个比较好的需求有点难。
设计过程就是将你确定的需求想办法用代码去实现。这个过程是交给程序员做的。设计可能会用到很多方面的知识。软件最终的目的是要用户使用。因此在程序设计时必须立足于操作简单、实用,并真正能为用户解决实际的业务问题。不能因为怕编程麻烦而将程序功能设计得过于简陋。这个过程可能会对已经完成的需求分析做些改进甚至推翻。为每个模块确定采用的算法。然后就是根据算法写代码。以前觉得写代码是最麻烦得事情,现在才发现写代码原来只是软件开发中最简单的一个步骤。到目前为止学了C,C++,还有java,熟悉的还是面向过程的C,面向对象的软件开发还有待于实践。在这个小项目的开发中因为没有要求写代码,所以也没有使用哪种程序设计语言的问题。但我想既然面向对象的软件开发有着比传统的开发无法比拟的优点加上现在java风靡全球,连比尔盖茨都说java是目前为止最优秀的计算机语言,学着用java开发感觉好点。看来以后要好好的学java了。
软件交付之前必须要测试。测试是保证程序质量的一项重要工作。但测试只能证明程序有错,而不能证明程序无错。所以任何软件系统都不能保证内部没有错误。为了确保软件系统的安全与可靠性,一方面要加大测试力度,另一方面要抓住测试重点。程序又是测试的重点。一个合格的测试员应该很熟悉别人的思维。但感觉程序员应该很反感测试员。软件开发是一项建设性工作而软件测试是一项破坏性工作。一个曾经做过测试的如是说,“做测试,我感到最多是在和程序员在吵架”。我觉得测试的基本要求就是找出产品的缺陷,用简单明了的方式表达给开发人员,心平气和才好办事。不管怎样,有了破坏才能使软件的免疫能力强起来。测试占了开发一半以上的时间和资源。
我在实习小项目中做的是测试的工作。由于没有源代码,所以只能做静态测试。测试过程感觉很不好。摆在我面前的只有个软件需求文档和详细设计文档,而且需求分析一大半也是我写的。现在才发现需求分析当时写的有多么的差劲。很多的问题都没有考虑到。而且发现设计文档中的软件初始结构图根本不是按照需求分析给出的数据流图转化过来的。详细设计文档呢,跟总体设计差不多,甚至连总体设计的一些要求都没有,比如接口的描述,从头到尾没有提到过。面对着那份详细设计报告,我无从下手,什么都没有。每个模块的细节都没有考虑。还是一个最最基本的框架。可事到如今又能怎么办,总不能把原来的抛弃自己在测试之前重新做个详细设计吧,只好硬着头皮测了。测试完成后感觉没一点收获。还不如看看书上的白盒子测试的例子体会多一点。报告打印了一点成就感没有。
软件维护是软件生存期中的最后一个阶段。实习没有这方面的要求。维护也不像其前面的几个阶段理论成熟。但维护不是一天两天就能解决的问题。自从软件开始工作,维护就从来没有停止过。所以维护是一个耗人力物力最多的一个阶段。具体维护的方法应该根据软件的开发方法来具体确定。维护是为了软件能健康准确更好的运行,但在维护的同时也可能因为开发方法的缺陷导致维护产生一大堆的副作用甚至可能使得情况变得更糟,会得不偿失。所以维护马虎不得一定要慎重对待。