什么是软件生产率
什么是软件生产率:软件生产率是指人均每月所能生产的有效源代码行数。
软件生产率的计算:软件生产率的计算通常比较困难,不仅要考虑编码阶段,还应包括软件生存期的各个阶段影响软件生产率的因素:人的因素:开发机构的规模和经验问题因素:问题的复杂性和设计约束或要求更改的次数过程因素:使用的分析和设计技术、应用的语言及评审的过程。
生产因素:计算机系统的性能和可靠性资源因素:开发工具、硬件和软件资源关于软件生产率的历史经验:1.一个组织中最优秀和最后进的人相比,其生产率比值是10:12.最优秀的和平均水平的人相比,比例是2.5:13.前一半和后一半相比,其生产率的比例大约是2:14.从同一个组织来的两个人,其生产率大致相同
影响软件开发工作效率的主要因素有哪些,并解释怎样才能提高软件开...
软件开发中的三种基本策略:复用、分而治之、优化与折衷1.复用 利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。
2.分而治之分而治之是指把大而复杂的问题分解成若干个简单的小问题,然后逐个解决。
3.优化与折衷软件的优化是指优化软件的各个质量因素,如提高运行速度、提高对内存资源的利用率、使用户界面更加友好、使三维图形的真实感更强等等。
软件开发的成本
展开全部 一、系统软件的成本构成 系统软件的成本作为一个经济学范畴,应反映软件产品在其生产过程中所耗费的各项费用,为原材料、燃料、动力、折旧、人工费、管理费用、财务费用待项开支的总和。
从财务角度来看,列入系统软件的成本有如下的项目: (1)硬件购置费如计算机及相关设备的购置,不 间断电源、空调器等的购置费。
(2)软件购置费,如操作系统软件、数据库系统软件和其它应用软件的购 置费。
(3)人工费,主要是开发人员、操作人员、管理人员、的工资福利费等。
(4)培训费。
(5)通讯费,如 购置计算机网络设备、通讯线路器材、租用公用通讯线路等的费用。
(6)基本建设费,如新建、扩建机房、购置计算机机台、机柜等的费用。
(7)财务费用。
(8)管理费用,如办公费、差旅费、会议费、交通费。
(9)材料费,如打印纸、包带、磁盘等的购置费。
(10)水、电、汽、气费。
(11)专有技术购置费。
(12)其它费用,如资料费、固定资产折旧费及咨询费。
从系统软件生命周期构成的两阶段即开发阶段和维护阶段看,系统软件的成本由开发成本和维护成本构成。
其中开发成本由软件开发成本、硬件成本和其他成本组成,包括了系统软件的分析/设计费用(含系统调研、需求分析、系统分析)、实施费用(含编程/测试、硬件购买与安装、系统软件购置、数据收集、人员培训)及系统切换等方面的费用;维护成本由运行费用(含人工费、材料费、固定资产折旧费、专有技术及技术资料购置费)、管理费(含审计费、系统服务费、行政管理费)及维护费(含纠错性维护费用及适应性维护费用)。
二、系统软件成测算 综上所述,系统软件的成本由软件的开发和维护成本所构成,即: C=C1+C2 (1) 式中:C为系统软件的开发成本;C1为系统软件的开发成本所构成;C2为系统软件的维护成本。
1、系统软件的开发成本C1的测算。
我们认为系统软件的开发成本按其工作量及单位工作量成本来测算是可行的,具体测算方法为按系统软 件的软件规模(一般为软件源程序的指令行数,不包括注释行)、社会平均规模指数以及工作量修正因素来 进行。
尤其是CAD系统软件的实际测算,结合国内外研究成果的综合分析和专家咨询,软件社会平均生产率 参数和软件社会平均规模指数可分别确定为3.5和1.3左右;软件工作量订由八个因子、五个等级组成。
2、系统软件维护成本C2的测算。
系统软件的维护为修正现有可运行软件并维护欺其主要功能不变的过程。
系统软件在其交付使用后,其维护阶段在软件生命周期或生存期中占较大比重,有的可达软件生存周期的50-70%。
因此,系统软件的维护成本是软件成本测算中不可忽略的一部分。
系统软件的维护包括三类:A、改正、纠正性维护;B、适应性维护;C、完美性维护。
其中C类是为扩充 功能、提高性能而进行的维护,在软件资产价值评估中一般不计入该系统软件成本,而A、B两类,则与软 件的开发过程有着紧密的联系,应计入软件成本。
在系统软件维护阶段,对软件工作量的影响因素与开发阶段的影响因素基本相同,是开发阶段影响因素 的后的影响。
因此,系统维护的可靠性越大,规模越复杂,隐错越难发现,纠错越难。
系统软件越复杂, 要使其适应软、硬环境变化,进行适应性维护也越困难。
当然,可靠性大、复杂度高的系统软件,其可维 护性要求也越高,软件在运行中出错的可能性也会少些。
基于上述分析,系统软件维护成本的测算,可按 系统软件开发成本乘以一个该系统软件的维护参数来求取。
这一维护参数,可按系统软件的复杂度从简单 到一般、到复杂的顺序,分别取0.15、0.20、0.25及0.30、0.35、0.40等。
计算机系统软件作为计算机系统的组成部分,是信息社会的重要商品,也是知识经济社会中的重要资产。
系统软件同其他计算机软件一样,具有如下的特点: 1、系统软件是由许多人共同完成的高强度智力劳动的结晶,是建立在知识、经验和智慧基础上的具有独 创性的产物。
系统软件的开发可以工程化,软件生产可以工厂化,因此,系统软件具有价值和使用价值。
同时,系统软件具有独创性(即原始性),所以软件著作权人对系统软件产品依法享有发表权、开发者身份权、使用权、许可权、获取报酬权及转让权。
2、系统软件产品是无形的,存在于磁盘等介质的有形载体中,通过载体进行交易。
因此,带有系统 软件的磁盘交换价值,是磁盘自声价值与系统软件之和,而且主要是系统软件的价值。
3、系统软件产品的复制(批量生产)相应简单,其复制成本同其开发成本比较,几乎可以忽略不 计。
因此,系统软件产品易被复制乃至剽窃。
为保护系统软件产品的著作权,必须依法登记。
4、系统软件产品一般没有有形损耗,仅有无形损耗。
系统软件产品的维护,一是由于系统软件自身 的复杂性,特别是为了对运行中新发现的隐错进行改正性维护;二是由于系统软件对其硬、软件环境有依赖性。
硬、软环境改变时,系统软件要进行适应性维护;三是由于需求的变化,要求增强系统软件功能和提高系统软件性能,系统软件要进行完美性维护。
因此,系统软件的维护...
软件能力成熟度代表什么?
展开全部围绕软件开发实践和方法论,总有很多教条式的口水仗。
阶段式(phase-gate)方法能够有效管理软件开发过程的风险,还是说只是风险管理中的花哨噱头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说,虽然缺乏证据判断这些论调的谬处,但有两条常用的法则能够帮助我们选择好的实践,同时,提升我们所提供软件的价值:划小开发周期以及提升反馈效率。
Michael Feathers给出了以下观点:我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细微差别。
坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。
或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实并非如些。
问题是,我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。
代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭,这并不是一个好的方法。
而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁钝,并导致低质量软件出 现。
目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式,招聘好的人才,是一门(招聘)艺术,而非(招聘)工程。
心理学家至少对这个问题进行了研究:为什么IT业的技能很难被掌握和度量?Daniel Kahneman说(Thinking Fast and Slow),掌握技能有两个基本条件:一个环境足够规律以便可预测;有机会通过长时间实践来学习掌握这些规律。
但是典型的软件项目往往是没有规律及可预测环境的。
项目成功的唯一正确度量就是:最终的结果通过整个生命周期里的实施达到了预期目标吗? 很难知道什么关键活动导致了项目成功和失败,很少有人能够通过旧有或现有的项目获得答案。
几乎不可能判定哪些决策导致了成功或失败(在人工智能领域,这叫作信度分配问题)。
这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。
然而,开发者掌握能帮助他们更高效地达到目标的技巧,将使他们更有动力 – 通常称之为“开发完成”,尽可能快的、不考虑是否功能被集成以及生产就绪。
类似的场景也常出现在其他功能性实施领域。
实际的软件项目是复杂的,没有规律可循,这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的,几乎不可能在脱离收集环境的情况下归纳出这些数据。
在Laurent Bossavit的好书《The Leprechauns of Software Engineering》中, 他抨击了软件开发的一些惯式,比如“成本变化”(或“缺陷成本”)“曲线”,这些惯式是许多其它的软件开发方法论知识基础,称开发人员生产率的变化是一个数量级(参照确定性金字塔原理)。
Laurent Bossavit说明了相关依据 – 很多人依赖从计算机科学专业学生进行的非正式试验或是从无法被有效控制的项目中收集小量数据。
这些研究组织的给出的论调基础往往是不健全的,数据缺乏分析,而且,最过分的是调查结果普遍远远超出了他们的适用领域。
因此,不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适,反之亦然。
“方法大师”的见解其实也没太大指导意义,就像Kahneman说的,“人们在想法方面的信心,并非是有效行事可倚重的因素…当评估专家的想法,即使在有规律可循的情况下,你也一定要想清楚是否有合适时机可以引入其想法的可能性”。
就像Ben Butler-Cole指出的(why software development methodologies rock),引入一种新方法往往会带来一些影响。
你可能会认为当我们决定怎样运作一个团队时,我们就陷入了被动。
但细想一下为什么软件开发无章可循?为什么在这个环境里很难进行一些试验以及获取技能?什么实践和决定会导致成功或失败?其中的根原因就是:环境是无规律的,做出变更与理解变更带来的结果之间的反馈过程太长了。
这里的“变更”一词是指广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。
还是有一些办法帮助缩短周期的,比如当我们应用精益软件开发思想 – 一个很重要的方法。
缩短开发周期在大型产品开发中是很重要的:在Bret Victor的精彩视频Inventing on Principle中提到,“如此多的创新被发现,只要你真正理解了你在做什么,你就能发现任何事物”。
但对我而言就是这样的:我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。
除非我们聚焦于尽可能使反馈间隔时间缩短,以便实际洞察其间关联,以及辨别原因和影响。
事实上,从想法到反馈的周期尽可能短的好处是如此明显和重要,应该把其作为商业模式中要遵循的一个重要原则。
如果你纠结于要把你的产品创建成一个用户安装式的软件还是...
软件危机有什么表现?
软件开发进度难以预测拖延工期几个月甚至几年的现象并不罕见,这种现象降低了软件开发组织的信誉。
软件开发成本难以控制投资一再追加,令人难于置信。
往往是实际成本比预算成本高出一个数量级。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量,从而不可避免地会引起用户的不满。
用户对产品功能难以满足开发人员和用户之间很难沟通、矛盾很难统一。
往往是软件开发人员不能真正了解用户的需求,而用户又不了解计算机求解问题的模式和能力,双方无法用共同熟悉的语言进行交流和描述。
在双方互不充分了解的情况下,就仓促上阵设计系统、匆忙着手编写程序,这种"闭门造车"的开发方式必然导致最终的产品不符合用户的实际需要。
软件产品质量无法保证系统中的错误难以消除。
软件是逻辑产品,质量问题很难以统一的标准度量,因而造成质量控制困难。
软件产品并不是没有错误,而是盲目检测很难发现错误,而隐藏下来的错误往往是造成重大事故的隐患。
软件产品难以维护软件产品本质上是开发人员的代码化的逻辑思维活动,他人难以替代。
除非是开发者本人,否则很难及时检测、排除系统故障。
为使系统适应新的硬件环境,或根据用户的需要在原系统中增加一些新的功能,又有可能增加系统中的错误。
软件缺少适当的文档资料文档资料是软件必不可少的重要组成部分。
实际上,软件的文档资料是开发组织和用户的之间权利和义务的合同书,是系统管理者、总体设计者向开发人员下达的任务书,是系统维护人员的技术指导手册,是用户的操作说明书。
跪求高手解下vb试题
软件危机的形成1. 硬件生产率大幅提高2. 软件生产随规模增大复杂度增大3. 软件生产率很低4. 硬、软件供需失衡5. 矛盾引发"软件危机"软件危机的具体体现1. 软件开发进度难以预测2. 软件开发成本难以控制3. 用户对产品功能难以满足4. 软件产品质量无法保证5. 软件产品难以维护有讲到: 软件生产率很低,质量无法保证,成本难以控制但A中的问题(软件过程不规范)没有提到,故选A
软件开发的程序员每月工资普遍是多少
展开全部 关于具用人单位的工资,以及其他福利待遇无法给出准确的答复。
但是,根据《劳动法》第四十六条 工资分配应当遵循按劳分配原则,实行同工同酬。
工资水平在经济发展的基础上逐步提高。
国家对工资总量实行宏观调控。
第四十七条 用人单位根据本单位的生产经营特点和经济效益,依法自主确定本单位的工资分配方式和工资水平。
第四十八条 国家实行最低工资保障制度。
最低工资的具体标准由省、自治区、直辖市人民政府规定,抱国务院备案。
第四十九条 确定和调整最低工资标准应当综合参考下列因素:(一)劳动者本人及平均赡养人口的最低生活费用;(二)社会平均工资水平;(三)劳动生产率;(四)就业状况;(五)地区之间经济发展水平的差异。
第五十条 工资应当以货币形式按月支付给劳动者本人。
不得克扣或者无故拖欠劳动者的工资。
...