软件工程心得论文.docx
- 文档编号:26930971
- 上传时间:2023-06-24
- 格式:DOCX
- 页数:9
- 大小:23.07KB
软件工程心得论文.docx
《软件工程心得论文.docx》由会员分享,可在线阅读,更多相关《软件工程心得论文.docx(9页珍藏版)》请在冰豆网上搜索。
软件工程心得论文
软件工程论文
以沟通为出发点,以沟通为中心进行项目的开展,可以有效地进行项目的管理,提高项目的质量,降低风险与成本。
沟通,不仅仅是指用言语进行沟通,还可以以书面,文档,手册,电话,邮件,会议等方式进行。
灵活运用多种的沟通方式,使参与项目开发的每个成员能够有统一的思想,不会产生歧义。
当然,沟通不仅仅是在工作上的沟通,也需要工作下的沟通。
简单来说,项目经理对员工的不同程度的问候,或多或少会提升员工的工作积极性与主动性。
而这也就升华到管理的层面,是管理项目,还是管理人?
可以从底层分析,项目是由谁来做?
是参与项目的员工。
那么项目的质量直接由什么来决定?
员工的工作心态。
但是员工的心理活动往往低多变的,没有人能够掌控,那么适当的沟通,不仅仅可以将这种情感活动向益于工作的方向转移,而且也可以进一步促进公司的凝聚力,让员工从心里将公司当成一个大家来对待。
而工作层面,适当的沟通,可以让彼此了解对方的思考方式,迅速的采取合适的办法,让彼此的意见得到统一。
而不是因为意见向左,产生分析,得不到进一步的解决。
从项目整体来讲,合适的沟通可以降低项目需求的多变性,从而降低项目开发的成本;合适的沟通可以将技术层面的难题,得到共同的思想靠拢,从而得到解决;合适的沟通可以让各岗位职责的人能够明白彼此的意见,提高工作效率的同时,也进一步降低因为沟通不当,导致项目BUG出现的几率。
沟通分层次,同一个层次的人群互相沟通,不会有太大的难度与理论上的偏差。
而针对不同领域,不同层次的人来说,彼此之间的沟通成为了一个难题。
所以从公司的角度分析,首先项目组成员必须具备最基本的理论基础,如:
《软件工程》,《软件质量》等。
从细节划分,编程人员需要有关于具体编码规范等额外理论基础,测试人员需要有关测试方面等额外理论基础,针对项目经理,不仅需要编程人员与测试人员的基础理论,也需要整个项目的理论,如《软件项目管理》,《项目管理知识体系》等管理知识。
只有理论背景差别大不的情况下,互相之间的沟通,才会更加有效率,进一步降低信息在传输之间的损耗,使开发出的软件更加接近客户的要求,提高客户对公司产品的满意度,有利于产品的市场推广。
所以完美的项目不存在,只能在共同的努力下,产品才能够向完美进一步靠近。
以下从项目的整体来阐述沟通对各个层次的影响。
竞标阶段,竞标的成败与否,在于自己的产品是否接近客户心中的目标,从而赢得投标,其中的关键在双方的沟通。
众所周知,项目从哪来,是从客户的需求得来。
那么从公司的角度出发,如何获得客户的认可,得到项目的投标?
这是个很现实的问题。
在《软件工程导论》上得到很多信息,如何快速开发出客户满意的模型,在于需求分析师从客户交流中,得到有用信息的有效程度。
其中的信息不仅仅是项目的功能,也有客户的背景,使用环境,客户群的习惯等等方面。
根据市场调研显示,客户的体验度已经成为一个不可忽视的环节,虽然所开发的系统已经完成了用户的基本功能要求,但是从客户最直接的感官出发,系统操作不够简便,系统画面不够人性化等等细节体现出,客户的满意度没有达到应该有的高度。
所以,中间的沟通也就成了关键。
作为项目前期需求的主导--需求分析师的素质成为了主要因素。
对于大多数人来说,获取对方话语的有效的信息量为80%,而经过需求分析师的再一次理解,到了开发人员的手中的文档的有效信息不到实际的70%,所以常常开发出来的软件无法达到满意的效果。
如何在沟通中获取全面的有效信息?
最有效,也最全面的方式,莫过于在沟通交流之前,需求分析师进行一次全面的市场调研,对该客户的环境,业务等方面进行理解与学习。
然后在此基础上,结合自己的理解与客户进行下一步的沟通,在客户的角度思考问题,用自己的话语阐述客户的各种需求,得到对方的肯定,最终整理出最满意的客户需求。
那么如何快速的让客户的需求,转变为可以看到到的物理模型,这里提倡使用快速原型法。
系统架构师根据前期的客户需求文档,运用axure等建模工具,快速有效地开发出前期的模型,使文字性的描述,转变为最直观的物理模型,不仅可以更清晰的展现用户需求,也可以更直观的确认该模型是否符合客户的要求,以及时作出合理的调整,作出让用户满意的模型产品。
开发模型的同时,成本的估算工作已经展开。
有了具体的值,才会有实际给客户的报价。
所以如何估算?
使用哪种方式估算?
以哪个项目为蓝本?
需要进一步的分析与思考。
结合自己学的知识,以及向前辈请教的经验,发现(UCP)功能点算法,(LOC)代码行算法,(WBS)工作结构分解法已成为主流。
对于UCP,主要用于面向对象的项目,LOC与WBS没有具体限制。
每个算法都有自己的优缺点,对于不同的项目,项目的不同阶段,使用不同的算法,能够很好地解决成本估算的问题。
其中具体估算的同时,经验也是非常重要的,经常性的去总结每个项目,详细具体到单元,功能的估算,收录成册,形成良好的循环,对于公司是至关重要的。
而这里是项目第一次的初步估算,是为赢得竞标的概要值,得到标后,需要进行详细的成本估算与具体商榷的价格。
理论与经验的结合,可以进一步精确项目的成本估算,对于项目下一步的开展,起到良好的前期铺垫作用。
公司得到竞标后,进入需求分析阶段,参与人员主要为需求分析师,系统架构师,项目经理。
主要输出为,详细的项目成本估算,项目进度估算与需求规格说明书,概要设计,详细设计等文档。
参与者之间,需要进行详细的沟通,达成思想上的统一。
项目成本估算与项目进度的估算越详细越好。
实际中,为了满足顾客期望的日期而造成的不合理进度安排,在软件领域比其他的任何工程领域要普遍得多。
而且,非阶段化方法的采用,少得可怜的数据支持,加上完全借助软件经理的直觉,这样的方式很难生产出健壮可靠和规避风险的估计。
所以在这个阶段,开发并推行生产率图表、缺陷率、估算规则等等,对于整个公司来说,最终会从这些数据的共享上获益,形成良好的循环。
分别来讲,在成本的估算上,推崇使用UCP(功能点算法)。
这种方法,可以将项目中的各个方面,包括各种风险都能够考虑进去。
其中,在风险方面,需要全面的分析整个项目,从整体分析,然后小到局部,考虑未来可能出现的风险,评估每个风险的概率,计算出对应的功能点,然后估算每个功能点的费用,从而得到比较理想的成本估算。
在进度的估算上,推崇使用WBS(工作结构分解法),将项目任务进行合理的细分,分到可以确认的程度,然后估算每个WBS要素的时间,从而得出整个项目的时间。
当然WBS也可以适用于估算项目的成本,这里因人,因项目而异。
灵活使用不同的方法,可以进一步精确最终的估算值,将风险减小到最少,利于下个阶段的展开。
在整个需求分析阶段,要将需求做的更细,更准确为目标,不断地与客户沟通,严格杜绝使用习惯性的想法,去掩盖客户的真实需求,沟通应该具体到每个功能点,得到客户的肯定后,进行下个功能点的沟通。
关注客户的颜色感官,操作习惯等细节方面。
尽可能全面的从客户的角度去分析问题,然后结合公司的技术,给用户合理的反馈,得到最终双方都满意的结论。
需求分析师需要具有良好的沟通能力外,也需要出色的理解分析能力,具备业务基础,项目成本评估,以及各种文档的编写能力。
一个成熟的需求分析师,可以将沟通中信息的损耗减小到最低,提高用户的满意度,整理出比较全面的《需求规格说明书》,有利于系统架构师的工作开展。
《需求规格说明书》得到后,系统架构师需要在此基础上,完成系统的架构,整理《系统概要设计说明书》与《系统详细设计说明书》,完成系统的前期搭建工作。
良好的系统架构师需要具有相关的知识与经验外,也需要很强的分析,解决问题的能力,战略规划能力,业务流程建模能力,信息数据结构能力等多方面的素质。
从细节方面分析,系统架构师需要从需求到设计的每个细节都要考虑,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单等等。
工具方面,熟练使用RationalRose、PowerDesigner等工具进行设计开发,提高工作效率。
在《系统详细设计说明书》完成后,参与项目的各成员需要进行评审工作,评审《需求规格说明书》与《系统详细设计说明书》,提出自己的看法与观点。
在总的设计环境下,寻找不足与欠缺的地方,尽可能去完美这个设计,发现以后可能要面临的问题,提前思考与解决,降低系统的开发难度,利于编码工作有力进行。
所以,各种文档的输出需要统一化,利于阅读人员的理解,也就是在书面的沟通上不会产生细想上的偏差,将理解上的风险降到最低。
所以在开发的初期,参与项目的各个成员必须达成思想上的一致,可以细致到需求文档中每个功能都是一样的理解。
如此,项目的最终产品,才会偏差最小,越接近用户的需求,达到更高的用户满意度,得到更好的业界好评。
综合考虑,需求分析阶段主要做四个方面的工作。
1.问题的识别,即双方确定对问题的综合需求,这些需求包括功能需求,性能需求,环境需求,用户界面需求等。
2.分析与整合,导出软件的逻辑模型。
3.各种文档的输出,即写出详细的需求规格说明书,用户使用手册,测试计划,测试用例,系统概要设计等文档。
4.评审与反馈,分为技术评审与需求评审,发现更多的问题,防范于未然。
编码阶段,主要为程序员之间的沟通,程序员与经理之间的沟通,程序员与系统架构师之间的沟通成为影响软件质量,项目进度的主要因素。
项目编码阶段,项目经理需要了解参与项目中的每个人的技术程度,这将是分配模块的困难程度的一个重要环节。
简单的模块交给技术不好的人来做,难的模块交给技术达人来做。
如果如此安排,新人还是新人,技术达人依然会更加忙碌,更加累,没有任何改变,也不利于公司的长远发展。
所以合理的搭配难易程度,让新手在编程梯度渐增与技术达人的合作环境下,快速成长,同时也缓解了技术达人的压力,可以将更多地精力投入到技术难点中,提高项目组整体的效率。
编码期间,对成本与项目进度的控制,也是项目经理的一个重要任务。
为了提前项目进度或者压缩项目成本,而采取不合理的工作安排,如经常性的加班,项目工作裁剪等手段,往往是非常致命的,不仅会使项目的质量整体下降,而且会使员工的凝聚力降低。
虽然如此做可以完成项目的功能目标,但是项目的后期维护将会是一个灾难。
而且不合理的时间安排,也会使员工心理产生不可控制的活动,从而对公司的长远发展产生隐性的影响。
这些往往是大多数经理人不会考虑的,对员工的忽视,导致员工的离职,成为社会的一个主流,这对正在进行的项目来说,会造成很大的成本与风险压力。
老员工的离职,新员工的进入,不仅仅是人员的改变,也是对开发团队的再一次整合,去熟悉新人的做事风格与思考问题的方式,期间所消耗的时间已远远超过培训的时间,而结果往往会延误项目进度。
通常当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。
这就像使用汽油灭火一样,只会使事情更糟。
越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
Brooks法则—“向进度落后的项目中增加人手,只会使进度更加落后”。
落后的项目不增加技术人员,唯一的风险也就是进度的延期,而增加人手,改变计划往往将增大项目不可控制的风险,而这些风险常常是致命的。
研究表明,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。
所以可控的项目进度,是项目经理所追求的,不断变化的环境,需要更加合理的方式去解决。
理想中,已经计划好的进度不会实现,只会因为不确定的因素而改变。
实际工作中,遇到项目进度的偏移,采取必要的增加人手往往是唯一的办法。
虽然每次估计项目的成本最终为人月的计算,但是人和月之间的互换,紧靠单纯的数据是显示不出来的。
每个人的编程风格的不一致,技术水平的高低,理解能力的不同,会造成或多或少的时间损失与成本损失。
更重要的是,每个人的性格不同,与人的沟通方式不同,融入新的团队,那么这会因为新人的加入而使整个团队发生”化学反应”,当然这里所说的化学反应可不是NBA那样,是促进型的。
再加上彼此之间的磨合期,适应期,互相熟悉彼此的代码风格等等,这些都隐含的消耗掉大量时间。
所以人月的互换,需要仔细的去更改原有的项目计划,以适应新的变化。
如果仅仅靠增加人手,而对应的项目不做相应的改变,那么最终的项目会超出应有的控制,向着不可预料的方向发展,最终的后果往往是不可承受的。
如何控制项目进度与成本,降低项目的风险?
需要项目经理全面地掌握项目进度的开发,那么其中会议的开展是必要的。
这里将会议分为两种,周例会与年例会。
每周定时的开会,讨论目前工作中所遇到的问题,对项目的风险与进度是有很大的好处,问题的及时提出,重大BUG的发现,并得到关注与解决,都会对项目的进度造成一定程度上的影响。
所以,前期阶段的问题排查与解决,对项目后期的测试与维护工作有很大帮助。
前期的努力在一定程度上降低了项目的成本。
当然,每周例会或多或少会留下少许的问题,或者重现的问题,这些问题会在时间上不断地堆积,所以必要的年会可以更好地解决这类问题,3个月或者6个月的大会也是最好的选择。
发现与总结前段时间的问题,可以更好地控制项目前进的方向。
另一点,这些会议不仅可以解决决策上的问题,而且可以使决策更容易被接受。
每个人都在倾听,每个人都在参与,每个人对复杂约束和决策之间的相互关系有了更透彻的理解。
也有利于员工对于有疑问的点,或者问题,尽可能与架构师或者分析师沟通,得到一个权威性的结论,而不是自己去猜测着去工作,埋下隐性问题,为以后的测试工作造成压力。
综上所述,一个优秀的项目经理人,对项目的开展有极其重要的作用。
那么项目经理,不仅在编程方面需要有一定的水平,而且在项目的管理方面,也需要有着丰富的经验。
由于项目在开展过程中,会遇到各种各样的问题,所以,具备良好的应变能力的经理人,对项目的持续开展有着极其重要的意义。
测试阶段,测试人员与程序员之间思想上的统一,在一定程度上决定了软件的质量。
通常我们将测试阶段分为单元测试,集成测试与用户测试,使用的工具为JIRA或者Bugzilla等缺陷工具。
单元测试是指对软件中的最小可测试单元进行检查和验证。
对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。
单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
所以,单元测试是由程序员自己来完成,最终受益的也是程序员自己。
程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。
但是在实际项目中,往往程序员比较理想化,测试自己的代码找不出明显的BUG。
所以,这里需要使用一种小组成对的方式,互相测试对方的代码,可以更明显的发现其中的问题。
中间就涉及到了沟通的问题,代码是他人写的,需要读懂彼此代码,就必须进行不断地交流,如此才能更好地进行测试。
而这个方式,不仅可以有效地发现彼此代码中的问题,也可以进一步加强团队里面人员的沟通,适应彼此之间的思维模式,提高团队整体开发效率。
虽然这个方式需要花费比较多的时间与成本,但是与维护中发现的BUG的成本相比,会有很大的差别。
其中这种方式,需要责任到人,才能体现出更好地效果地方。
集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。
实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。
程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。
所以对集成测试的工作,必须加强落实,而不能像走过场一样,简单走遍流程,功能实现就结束,应该将所有出现的细节问题得以重视,并且及时反馈信息,得到有效地解决。
集成测试期间最主要的参与人员为测试人员,但反馈的信息,需要开发人员的确认,所以两者之间的沟通成为必然。
测试人员如果发现问题,如何将自己的思想有效地传递给对应的开发人员,成为一个问题。
通常过程中,我们是以书面或者口头上的简单陈述来表达问题,但是往往发现,同一个问题,需要多次返工,才能得到有效地解决。
而这里,提倡使用图形,BUG重现与文字结合的方式,更加清晰地反应问题的实质,指明要点,如此可以进一步减小因为沟通上的原因,造成返工的次数。
而总体来说,在集成测试阶段发现的BUG越多,对后期维护的压力越小,维护的成本越低。
所以集成测试期间,需要全员的配合,共同努力,发现系统的问题,调高软件的质量。
在完成单元测试与集成测试的基础上,进行最有一步的用户的测试。
当然,这里最好的方式,是将软件先交付给项目组以外的成员,开辟一段时间去使用。
而是这些成员不需要懂软件,是从用户的角度出发使用软件,发现其中的问题。
当然,从项目的整体来讲,这里的测试使用,可以从项目的里程碑开始,每完成一个里程碑,就可以进行测试,及时的反馈信息,使其在开发阶段得到解决,可以提高软件质量的同时,也节约了时间的成本。
从公司长远的角度出发,这个模式,可以降低项目的风险,提高项目的质量,也可以使公司得到更高用户的满意度。
测试完成,交付产品后,也就进入了最后的产品维护阶段。
从实际上出发,没有完美的软件,只有更好的软件。
所以在实际运行过程中,必不可少的会出现各种BUG,如何处理这种问题,出现问题如何让客户的损失减小的最低,以提高客户的回顾率,成为了至关重要的方面。
研究表明,项目在维护阶段的成本往往会高达40%,也在一定程度上,降低了公司的认可度。
所以项目完成后,项目的文档与经验必须整理成册,以方便项目的维护。
其中人员的流动,会对已经完成的项目造成很大影响,所以在维护阶段,不仅要与用户进行沟通,得到新的需求,而且与项目组成员的沟通,也比以往要注重许多。
虽然项目已经取得阶段性的胜利,但是只要这个软件还在使用,就会出现问题,就需要软件升级,需要开发新的版本。
所以原有的项目组成员,如果有过多的流动,那么新组成的团队,不仅需要更多时间去熟悉项目与团队,而且阅读理解原有的代码会有很大的阻碍。
虽然人员的流动,是无法避免的,但是如何将这种损失减小到最低,也是需要更多的关注。
在单元测试阶段的成对测试,可以解决一部分问题,加上已经收录成册的文档,只要不是大量的人员流动,那么项目团队的骨架依然存在,对公司的损失也会减小到最少。
以上就是自己对软件工程项目整体的看法与观点,从沟通出发,找出问题的所在,不仅降低了项目的风险,也增加了彼此之间的了解,从项目层次出发,提高了项目开发的效率与项目的质量。
从用户的角度出发,得到了更好,更完善的产品。
从公司的角度出发,提高了人文元素,增加了员工的归属感,增强了公司的凝聚力。
所以,只有沟通,才会无限可能。
最新文件仅供参考已改成word文本。
方便更改
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 心得 论文