软件开发与应用心得体会.docx
- 文档编号:27893434
- 上传时间:2023-07-06
- 格式:DOCX
- 页数:11
- 大小:23.47KB
软件开发与应用心得体会.docx
《软件开发与应用心得体会.docx》由会员分享,可在线阅读,更多相关《软件开发与应用心得体会.docx(11页珍藏版)》请在冰豆网上搜索。
软件开发与应用心得体会
软件开发与应用心得体会
篇一:
APP学习心得
Android学习心得
XX年1月28号,我们正式开始了我们的冬季小学期课程——android的研发。
在老师们的介绍下,我们接触到了android的开发环境以及控件的功能。
刚开始接触Android觉得既陌生又亲切,陌生在于没有学过具体的开发软件,亲切在于它在界面开发上和web也可以形成了相通的架构,更加方便。
通过十几天的学习,接下来说说我的收获:
在这次android的学习过程中,我了解到:
一、android基础知识:
1.环境的配置:
(1)配置Java程序开发环境;
(2)安装并汉化Eclipse(JDK);
(3)AndroidSDK的安装;
(4)ADT的安装及配置;
(5)Android模拟器的配置。
2.第一个简单的Android程序(HELLOWORLD):
(1)创建一个Android应用程序:
打开eclipse开发工具——文件——新建——项目——android——androidproject——下一步,
(2)应用程序编写:
完成程序资源的设置;完成界面布局的设置;完成程序的事件处理;完成程序的总体配置;应用程序测试;部署应用程序到Android手机(对APK应用程序进行打包)。
3、控件:
在Android学习中,每一个应用都需要一些空间,在这一个月的学习当中,我们也接触了很多的控件:
(1)TextView:
用来显示文本标签的控件;
(2)ListView:
用来显示一个列表的控件;
(3)Toast:
是Android用来显示显示信息的一种机制;
(4)EditText:
编辑框,用于输入信息;
(5)RadioGroup、RadioButton:
单项选择;
(6)Checkbox:
多项选择;
(7)Spinner:
下拉菜单;
(8)AutoCompleteTextView:
自动提示;
(9)DataPicker、TimePicker:
时间和日期事件;
(10)Button:
按钮;
以上的控件,可以使我们制作出一个的手机软件,使用起来更加的方便。
我们还学习了java的基本概念以及java编程基础知识。
因为要制作一个手机软件,就要看懂背后的代码,这样才能解决问题。
总结了知识点,紧接着说说我的心得体会:
在为期半个月的学习过程中学到了很多知识,受益匪浅。
在课上,老师举出了一些简单的例子,紧接着当天下午我们开始上机操作,这样可以及时地巩固我们所学的知识点。
通过十几天的android学习,我们基本掌握了Android应用程序开发的一般流程。
对常用控件基本掌握其用法,对其事件的监听方法也基本掌握。
学习Android不仅是对前沿开发技术的了解,也是对编程知识的一次提升。
在这次android的入门学习中,我们还要分小组进行编写程序,然后进行作品展示。
现在回想起来,那时展示时间快到了,我们小组还没有布局好,也没有美化好,心里很着急,甚至还老是出错,不能正常运行。
我们着急得睡不好觉,为了一个美化布局,我忙了三天,现在想想那时,看来自己对于配色还是有待加强学习啊!
不过,最后在老师的帮助下,我们还是顺利完成了作品展示,虽说美工不是很好,但是我们尽力了。
相信今后我们会更加努力地学习配色,因为一个作品的重要性不仅在于功能,而且用户体验也很重要,美工是一部分。
在这次制作软件中,我觉得小组的分工与协作是非常重要的,如果不分工,这样就会导致作品出错,而且会浪费时间,比如说:
在没有明确的分工下,我找资料,我的组员也去找资料,这样就会导致工作重复,浪费一定的时间。
所以说合作的关键在于同心、分工明确。
幸好我们小组分工明确,这样才按时完成任务。
总之,在这次学习中,我获得了很多东西,提高了自己的编程技巧和编程方法,并且认识了Android应用程序的开发,以及加深了对Java的认识。
最后,我还要感谢我的老师们!
因为你们的用心指导、用心付出,才有我们现在的作品。
老师们,谢谢!
篇二:
软件工程学习总结和体会(自己总结)
软件工程I课程考核报告
学号:
1115115285
姓名:
王瑞博
专业:
软件工程
班级:
11软工软件一班
指导教师:
李生
南阳理工学院软件学院
XX年5月
软件工程课程学习总结
以前从没学过软件工程这门课,只是听学长学姐们说过,这是一门很深奥的课程,据说是有工程师称号的高手才摆弄的东西。
学过之后才发现,其实这门课真的很高深,就连老师也说他也有很多问题还没有解决呢。
下面我就谈谈我个人在本学期学习中一些总结和体会,希望对为学习本课程的人有一些帮助。
一、软件工程基础
什么是软件工程呢?
软件工程是一类求解软件的工程,为了克服软件危机,人们研究和借鉴工程学的原理和方法,形成了一门新的学科—软件工程学。
目前比较认可的一种定义是:
软件工程是为了研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何让把经过时间考证而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
从以上这些关于软件工程的定义,我们可以对软件工程这门工程学科有一个全面的整体性认识。
软件工程学的主要内容包括:
1、软件开发方法(需求分析、设计、编程、测试和维护);2、软件工具(泛指开发一切帮助开发软件的软件);3、软件工程环境(以软件工程为依据,支持典型软件生产的系统);4、软件工程管理学(对软件工程生存期内的各个阶段的活动进行管理)。
(一)软件工程的三要素和基本目标
1、软件工程以关注软件质量为目标,由过程、方法和工具三要素组成。
(1)软件工程过程:
在软件工具的支持下所进行的一系列软件工程活动,它是将技术层结合在一起的凝聚力,使得计算机软件能够合理地和及时地开发出来,是生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。
(2)软件工程方法:
完成软件开发任务的技术方法,它依赖于一组基本原则,这些基本原则控制了每一技术区域,且包含建模活动和其他描述技术。
软件工程方法学主要包括传统方法(结构化方法)和面向对象方法。
(3)软件工程工具:
是对过程和方法提供了自动的或半自动的支持。
软件工程三个要素之中软件工程过程是基础,方法是实现过程的技术,工具为过程和方法提供自动化或半自动化支持。
三者以有组织的质量保证为核心。
2、软件工程的目标是提高软件的质量与生产率,最终实现软件的社会化大生产。
(二)软件工程原理
软件工程专家学者们总结了开发软件的经验,提出了软件工程的7条基本原理。
这7条原理被认为是确保软件产品质量和开发效率的原理的最小集合,又是相互独立、缺一不可、相当完备的最小集合。
这7条原理是:
1、用分阶段的生命周期计划严格管理。
这是吸取前人的教训而提出来的,在整个软件生命周期中应指定并严格执行6类计划:
项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行
维护计划。
2、坚持进行阶段评审。
软件的质量保证工作不能等到编码结束之后再进行,应坚持进行严格的阶段评审,以便尽早发现错误。
评审过程应该包括完成者在内的各种不同角色的人参与,利用人的差异提高评审质量。
3、实行严格的产品控制。
开发人员最痛恨的事情之一就是改动需求。
但是实践告诉我们,需求的改动往往是不可避免的。
这就要求我们要采用可续的产品控制技术来顺应这种要求。
也就是要采用变动控制(基准配置管理)。
当需求变动时,其他各个阶段的文档或代码也随之变动,以保证软件的一致性。
4、采纳现代程序设计技术。
采用先进的技术既可以提高软件开发的效率,又可以减少软件维护的成本。
5、结果应能清楚地审查。
软件是一种看不见、摸不着的逻辑产品。
软件开发小组的工作进展情况可见性差,难以评价和管理。
为了更好地进行管理,应根据软件开发的总目标及完成期限,尽量明确地规定开发小组的责任和产品标准,从而使所得到的标准能清楚地审查。
6、开发小组的人员应少而精。
开发人员的素质和数量是影响软件质量和开发效率的重要因素,应该少而精。
有以下原因:
(1)高素开发人员的效率比低素质开发人员的效率要高几倍到几十倍,开发工作中犯得错误也少的多。
(2)当开发小组为N人时,可能的通信信道为N(N-1)/2,可见随着人数N的增大,通信开销将急剧增大。
7、承认不断改进软件工程实践的必要性。
这是基于上述六条基本原理的总结和归纳。
(三)软件的生存周期
一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。
软件的生存周期可分为八个阶段:
①问题定义;②可行性研究;③需求分析;④总体(概要)设计;⑤详细设计;⑥编码与单元测试;⑦综合测试;⑧软件维护等。
(四)软件开发模型
瀑布模式:
是传统的软件开发模式,其中的“瀑布”是对这个模式的形象表达,由山顶倾泻下来的水,自顶向下、逐渐细化。
其特点是:
线性化过程;分为分析、设计、编码、集成等几个阶段,并且各阶段逐级推进,不允许跨越。
里程碑管理;阶段评审;文档驱动;简洁便于工程应用的线性化过程步骤,并可以通过里程碑管理机制而使项目进程量化。
其明显的优点就是没个阶段结束前都要对所完成的阶段成果进行评审,这使得软件的错误能够在个阶段内尽早发现并尽早解决,总的来说瀑布模式具有良好的质量保证机制,有很强的生命力。
原型进化模式:
对软件进行直接模拟或仿真,只需要分析需求框架后进行原型创建,再对原型系统进行逐步细化与完善,通过版本更新逐步满足用户对于软件的多方面需要。
增量模式:
开发过程有三个任务域,分别是设计结构、开发构件和集成系统,它既有完善的工程管理机制,又能适应用户需求变更,有
篇三:
软件开发实习心得
软件开发实习心得
一直以来期望从事自己喜欢的事业的我,对软件开发有者及大的兴趣,可由说种种原因使我从事工作以来走了好几年弯路,心中的梦想迟迟不能得以实现,可程序员的梦想从来没有从我的心中抹去,但这扇大门好像并没有向我敞开,今天,贵公司给了我敲开这扇大门的机会,让我真实体验了程序员的诞生过程。
早就听说,程序员的前几个月是最苦的,可从来没有感受到,海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑,再也没有在自己家里随便写段小程序后的那种“自豪”感了。
要面对每天必须面对的问题,再也不可能以“逃避”而了之了。
也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。
团队精神和协作能力是程序员应该具备的基本素质,最近的工作中让我深深休会到了这一点,由于小组成员配合不好,使本来很方便的cvs给自己的工作带来的及大的麻烦,一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉,一整天的工作可能就这样被反工,我们小组这次就是因为协作不好,导致各模块之间不法连接,给工作带来了及大的麻烦,消耗了大量的劳动力还没有提高工作效率。
这使我深深的体会到:
一个成功商业性软件的开发必须有一个有强大凝聚力的团队,个人的力量是有限的,团队精神和良好的协作会使我们做出优秀的软件。
良好的文档是正规研发流程中非常重要的环节,作为代码程序员,30%的工作时间写技术文档是很正常的,缺乏文档,一个软件系统就缺乏生命力,在未来的查错,升级以及模块的复用时就都会遇到极大的麻烦。
这次的这个小小的项目,就因为文档上的一点点理解错误让我们花了很大的工夫去改代码,改页面。
很庆幸的是,这是一个小项目,要是大项目,这种问题可能就会导致大量的代码修改,可见文档在一个项目中起者巨大的做用。
此外,良好的代码编写习惯,不但有助于代码的移植和纠错,也有助于不同技术人员之间的协作。
作为一个程序员,对需求的理解能力也是很重要的,只有真正理解了一个模块的作用,才会写出高效率的代码,才能使整个软件项目作出来更加优秀,具备更好的安全性和稳定性,我在写代码的过程中就遇到了需求理解上的问题,使得写出来的代码功能不全,幸好不是给客户发现在,要不,这个软件的商业价值可能就会打折扣了。
单元测试对于一个程序员来说是不可不做的一项工作,不做好测试就会给后期的集成工作带来麻烦,往往为了一个小问题会让我们查找好多模块,给后期工作带来很大麻烦。
这一段时间的工作也让我明白了一点:
一个优秀的程序员必须不断的学习,随时总结,找到自己的不足,这样逐步提高,才能让自己很快的成长起来。
建站侠客发表于XX-4-2810:
19
对软件开发的一点心得体会
一、前期规划:
我理解的前期规划是:
在市场人员们汇总一个需求提交给产品专家带领的产品经理团队,然后经过这个团队根据公司具体情况再次分析和规划出一个最终需求文档。
这个需求文档应当首先提交给技术研发部门的负责人以及核心开发人员。
由开发团队对其进行技术和风险分析。
如果对此需求统一有异议的地方,需要返回给产品团队,重新修正需求。
反复如此,直至需求完善准确,细致,清晰。
前期规划就像高楼的地基,如果马马虎虎,就算是一块砖块没摆好都可能导致整个高楼建设的失败。
在规划中我认为,交流永远是需要双方积极主动,能认真听取每个人的建议。
前期工作思维不慎重,不细致,不认真,不够完善,将产生连锁效应直接导致整个工程和项目的失败。
这种失败可能表现为:
第一种,软件按需求实现但是功能根本不能满足用户需要。
第二种,功能都有了,软件没有达到可用性、易用性。
对于第一种,当然是因为前期规划疏漏了某些细小功能,没能把需求文档做完善。
应该是规划工作做的还不够认真和细致。
对于第二种情况,我认为更多是在产品设计规划方面经验还不够成熟。
这种问题应该是很难避免的。
因为每种新产品对产品团队来说都很陌生。
即使以前做过类似的东西,也难免面面俱到。
这只能通过不断努力和认真的态度来弥补。
前期规划的交流涉及了市场、产品和技术研发等多个团队之间。
需要的不仅是团队内部的交流,更多需要协调好团队之间的交流。
可能有时候需要公司高层和中层参与协调。
目前,很多开发人员深感项目的需求文档写的都很单薄。
大家可以想一想,如果没有好的开始,怎么会有好的结束呢?
需求文档单薄,不够细致,由谁来继续完善呢?
难道让程序员们自己去完善。
我想程序员也可能没有这种能力。
对于程序员能把代码写的很健壮很稳定就已经是很不容易的事情了。
二、概要设计:
我理解的概要设计步骤:
(以项目为中心的开发流程)
1〉项目经理仔细阅读项目需求文档。
2〉项目经理召集项目开发成员,开项目启动会议。
具体商议项目的开发任务和责任分配。
3〉核心开发人员开发确定,以及各模块开发人员确定。
4〉由系统分析员和核心开发人员仔细阅读需求文档,对系统整个架构分析和做技术规划。
5〉系统分析员整理和书写最终的系统架构和概要设计文档。
6〉系统分析员在文档提交日,提交给项目经理。
项目经理确认文档并审批。
7〉项目经理召集项目开发成员,开一个概要设计以及系统架构确定的会议。
向每个成员分发文档,并讨论确定最终概要设计文档。
8〉开始详细设计文档的工作
三、详细设计:
1〉项目经理组织成立各个模块的开发小组,并确定开发小组组长(程序经理)。
2〉各开发组长书写各自模块的详细设计文档,开发成员需要协助,配合。
3〉在指定提交日,开发组长提交文档给系统分析员。
由系统分析员审批。
4〉系统分析员组织召开一个详细设计文档确认的会议。
5〉然后开发组长分发各自模块的详细设计文档给程序员,程序员在指定时间内完成。
6〉程序员做内部测试。
开发组长协调并配合。
7〉确认无bug提交给开发组组长。
8〉所有模块整合工作,由整个开发组成员参与完成。
由所有开发组长和系统分析员负责主要部分工作。
程序员协助和配合。
9〉对整合后工程做详细测试。
10〉确认测试通过后,开发组长根据开发成员表现以及提交成果填写绩效考核表。
然后提交给项目经理。
11〉项目经理会召开项目总结会,同时向优秀成员颁奖。
同时鼓励所有成员继续努力。
对不能按时完成导致项目能按时提交,以及对导致失败的
关键人员给与惩罚处理。
当然,以上只是一个简单的开发流程,一定是有很多不足的地方。
希望能起到抛砖引玉的作用。
大家都明白,流程和制度是死的,但人是活的,所以如何按流程做得好,关键还是在人本身了。
没有一个流程和制度,一个团队也必将是一盘散沙。
正所谓“无规矩无以成方圆”。
这句话说得很有道理。
四、具体编码:
开发几个项目之后,对编写程序有了更进一步的了解。
好的程序应该具有:
易读性,易扩展性,容错性。
易读性:
所有变量和函数以及类名用简单易懂易记忆的命名方式。
所有类和函数甚至变量都有关键的注释说明。
这点很重要,也是最基础的。
如果代码书写不够美观和易懂,我想自己以后也不想再看。
就更别谈功能的扩展和新版本开发了。
易扩展性:
整体系统架构逻辑简单清晰。
模块与模块之间尽量做到互不影响,也就是尽可能的独立。
这部分工作主要体现在前期设计工作中,需要掌握好的设计经验和方法才能够做得比较好。
容错性:
对数据流和指针以及数组都做数据有效性检查;对第三方接口的调用失败的容错性。
对所有代码都做调用失败后的错误处理。
以及在大的工程中加入trace文件输出,把关键的数据流和关键处理部分的操作信息输出。
以便对工程异常情况产生条件的定位,及时解决问题。
我觉得程序员能在这三方面做得很好就算一个优秀的programmer了。
五、调试、跟踪与测试:
1测试需要注意的:
对每个模块的接口做测试,数据边界的检查。
在对整个模块做测试。
主要测试稳定性,效率以及功能是否正常。
确认单个模块完全正常后,再加入工程。
在系统架构设计的时候,可能会引入原型参考。
要对原型做完成测试后,确认没有问题后,才可使用。
2可以采用VC自带Trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息,以便定位程序异常的原因。
3对于通信模块的测试,特别注意服务端和客户端的数据流。
可以针对性的写一个客户端或服务端的测试程序,检验通讯过程是否正常。
4在用VC做开发中,一定先要让Debug版本正常运行,保证没有任何异常,内存泄漏和Assert等调试警告信息。
如果用到其他Lib,一定要保证Lib本身不存在问题。
这里只是提到一些自己容易忽略的东西,希望能对大家有所帮助,欢迎指正!
谢谢。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 应用 心得体会