软件开发总结

本学期杨红丽老师为我们带来了软件开发这一节课。

在这节课之前,我也编写过不少代码。但那些都不是“软件”,而是程序。

因为在系统的学习这个课之前,我对于代码的编写都是知其然不知其所以然。基本上都是脑子一想,就往下编,基本完成后再慢慢调试修改,所以经常在最后发现结构上的缺陷,要不程序大改重写,要不然牺牲性能,强行完成程序。哪怕是进行设计,也基本上就是个流程图设计,和一个类图的构思。

但是学习了这个课后就不同了,UML图中多种多样的图都可以用来描述程序的结构,在程序编写之前,就能够详细的想象出程序的功能,数据变化。这样,在编写之前就能够及时的发现错误,极大的降低了错误成本。

同时,在结对项目和团队项目中应用了这些知识,增加了我对于他的掌握程度,确切的增加了我解决实际问题的能力。

时间: 2024-10-14 01:30:59

软件开发总结的相关文章

结构化方法和面向对象方法在软件开发中的对比

学习过C语言和JAVA的同学们一定清楚,这两种语言代表了两种不同的开发方式,即以C语言为代表的结构化开发方法和JAVA代表的面向对象的开发方法.由于二者在程序结构上有着很大的区别,因此,在软件开发领域中,根据自己的需求来选择合理的开发方式就显得尤为重要. 开发软件通常有三个层次: 1.满足用户需求 2.可维护性,即可修改性,让软件能随着用户需求的变更而容易改变 3.可重用性(在其它软件中,能尽量重用该软件的模块) 通过对软件的这三个主要层次的分析,我们就能在实际开发中确定我们的选择. 结构化方法

敏捷软件开发简述

前言:由于我读了邹欣老师的<构建之法:现代软件工程(第二版)>,因此对敏捷软件开发有了比较大的兴趣.于是我在网上找了一些论文,比如Requirements Engineering and Agile Software Development.A decade of agile methodologies: Towards explaining agile software development.在读了这些论文之后,对敏捷软件开发有了大致的了解.这篇博文主要是简单介绍敏捷软件开发,重点集中在主

敏捷软件开发VS传统软件工程

敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,

全新的跨平台app软件开发工具——Lae软件开发平台

Lae是一款运行于windows的界面开发工具,具有所见即所得.开发跨平台.UI布局自由.机制简单.维护容易等诸多优点,可以开发同时运行在windows.Linux.MacOX.iOS.Android等系统平台的软件,windows桌面工具软件.管理软件.游戏界面;  linux系统桌面工具软件.管理软件.游戏界面; Mac OSX系统上桌面工具软件.管理软件.游戏界面:安卓系统的APP软件.2D游戏:iOS系统上的APP软件.2D游戏. 感兴趣的朋友请搜索知乎上的Lae软件开发平台介绍,或加入

怪不的软件开发这么挣钱,原来是有这么多职位

说起软件开发,现在是无人不知,无人不晓.好多人可能以为软件开发就是做一样工作的,其实不然,软件开发也分很多种类型,很多方向.做为一个过来人,简单介绍一些常见的开发方向. 1. 桌面程序:Java.C++.C#.VB.C均可. 现在大家办公使用的还是桌面程序占多数,不管是OA,ERP等等,都是通过PC来操作,桌面程序开发是一个重要的方向.只要PC还在,桌面程序开发就会一直存在. 2. 网站服务器端开发:JSP(Java语法).PHP.ASP(C#语法).Web App框架等 互联网发展的一个重要部

对软件开发中uml建模的理解和图形整理(一)

由于uml(统一建模语言)在开发中经常会用到,特别是在软件开发中的OOAD阶段,因此要理解和使用uml显得尤为重要.在uml开始之前,咱先回顾一个OOAD.OOP的主要特征. OOAD:根据面向对象的方法学来对软件系统进行分析和设计的过程.它包括OOA 分析阶段和OOD设计阶段.其中分析阶段主要解决"What to do?"的问题,而设计阶段主要解决"How to do?"的问题.具体来说就是:在OOA分析阶段咱要做的主要工作就是建立对业务问题域的视图(建立模型).

让你提前认识软件开发(46):首先是为人编写程序,其次才是计算机

第3部分 软件研发工作总结 首先是为人编写程序,其次才是计算机 "首先是为人编写程序,其次才是计算机",这是软件开发的基本要点,软件的生命周期贯穿于产品的开发.测试.生产.发布.用户使用.版本升级和后期维护等长期过程中,只有易读.易维护的软件代码才具有生命力. 在实际的软件开发过程中,可能是由于工作很忙的原因,很多开发人员只注重实现程序的基本功能,而忘记了编程规范,因此写出来的代码只能让计算机看懂,人要看懂很不容易.更有甚者,有些项目组为了赶进度,明确要求组员以实现产品功能为主,代码能

【转载】软件开发启示录——迟到的领悟

作者: John Sonmez  来源: IDF实验室博客  发布时间: 2013-10-20 15:47 转自(http://blog.idf.cn/2013/09/4-things-i-wish-i-would-have-known-when-i-started-my-software-development-career/) 我的软件开发生涯开始于15年前. 但是直到最近的5年,我才真正开始看到自己在软件开发领域的巨大进步. 这里有一些感悟是我希望能够在我进入软件开发领域时所知道的事情,如

软件开发质量管理的一些思考

PMBOK里关于质量管理主要有3个过程: 制定质量管理计划 质量保证(QA) 质量控制(QC) 书看了5-6次,还是发现比较抽象,难以理解. 实际项目中,如何才能合理的考虑各种资源制约,更好的执行质量管理呢? 一般的正规流程大致如下: 需求分析-> 客户评审与确认-> 概要设计->内部评审-> 详细设计->内部评审->编码-> 代码审查->单体测试 -> 集成测试->问题修复-> 代码评审-> 测试确认-> alpha测试-&g

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来