软件开发 原则 软件开发六大原则
- 作者: 喻大大大
- 来源: 51数据库
- 2020-04-15
APP软件开发都要遵守哪些原则？
随着APP设计开发的流行，所需要注意的细节非常多，需要把握的原则也有不少，今天重点和大家介绍下APP设计开发主要把握哪三个重要原则。
第一：趣味性：有一句话说的好么，兴趣是最好的老师。
其实很简单，你的产品如果不能够引起用户的兴趣，用户就没有理由选择你的产品，完全可以挑选其他的APP。
你说我的产品对于用户来说是刚需呀！好的，放心，当另外一个产品出来的时候就是你的产品game over的时候，除非他的比你的还烂，还让用户产生不了兴趣。
第二：故事性：不管什么样的产品，使用者终归是人。
而人是感性的动物，举个例子，我们小时候为什么都要妈妈讲故事我们才睡觉呢？因为如果你的产品如果充满了故事性的话就会将人带入到那个环境中。
形成一种用户是主角、参与者的感受。
这样对于产品生命周期是有很大帮助的。
第三：实用性——解决实际问题：这个直接拿实例说，不说微信啥的，就说前段时间政府封掉的打车软件。
不讨论打车软件的体验问题，也不说打车软件和某些部门之间的关系。
就说为啥这东西很多人需要？因为他解决了城市中打车难的实际问题，其中的一个功能加价功能更是如此。
有的时候有人需要办急事，这时候钱在他的脑海中优先级已经靠后了，所以他愿意多花一些钱甚至几倍的假期找到一辆出租车去帮他解决问题。
手机APP软件开发需要注意四个细节手机APP软件开发需要注意哪些细节。
随着电子产品的发展和普及，手机APP开发成为了当今非常热门的行业，很多企业和商家都有了自己的APP，通过APP推广业务和产品，不少企业也获得了不小的收获，所以手机APP软件开发成为了企业注重的一个项目。
接下来为大家具体分析下手机APP软件开发需要注意的四个细节。
第一点：尽量少让用户输入手机输入不如传统PC鼠标加键盘输入这样灵活，如以能不让用户输入的地方尽量不要让用户输入，能用选择代替输入的地方尽量用选择代替输入。
第二点：APP的用户和Web用户习惯不一样，手机屏幕尺寸和交互方式与Web不同，要求在产品设计阶段就必须考虑手机用户的使用习惯和手机的网络环境等特有的问题。
开发APP不像Web那样随时都可以更新，所以要对版本进行规划。
在功能上要有取舍，不能一股脑全部堆上去。
第三点：合理使用权限在满足需求的同时应合理使用权限，尤其是像访问通讯录、获取用户短信这种用户非常敏感的权限。
开发过程中最好是先适配低版本的SDK，再去兼容高版本的SDK。
这样比起先适配高版本的SDK，再去兼容低版本的SDK会省去很多麻烦。
第四点：符合各平台APP开发及操作体验习惯：如微信，在微信android 5.1版本以前在android平台上的操作体验就是ios的风格，其中种种原因大多由于起初腾讯为微信团队分配的资源较少，所以微信在ios 和android两个平台用了同一套UI及操作体验，但随着微信的逐渐强大，在微信android 5.1版开始就为微信单独设计了一套适合于android用户的操作体验。
个人建议android开发操作体验借鉴google自身的APP；苹果操作体验也参照苹果内置APP及市场中比较热门的APP。
软件开发过程中要遵循哪些软件工程原则呢？
项目计划制定的原则 1、 目的性。
任何项目计划的制定应当围绕项目目标的实现展开。
制订计划的第一步就是必须分析目标、进而找出为了完成目标所要完成的所有任务。
2、 系统相关性。
项目计划由一系列子计划组成，如范围计划、人力资源计划、进度计划、资源计划、质量管理计划、风险管理计划等等。
各个子计划不是孤立存在的，彼此之间相对独立，又紧密相关，应当形成一个有机的整体。
构成项目计划的任何子计划的变化都会影响到其它子计划的制定和执行，进而影响到项目计划的正常实施。
3、 经济性。
项目不仅要有较高的效率，而且要有较高的效益，因此计划过程是对多种选择权衡、优化的过程。
考试大整理 4、 动态性。
由于项目环境一般处在变化之中，特别是软件开发先把棺木的多变性，经常使计划的实施偏离项目的基准计划，因此项目计划要随作环境和条件的变化不断调整和修改，以保证项目目标的完成。
如何防止项目计划多变，对出现的问题及时加以处理以保证进度按原计划实现，在一定的意义上说甚至是更为重要的。
防止项目计划多变，就要改进计划的编制工作，提高计划的质量，这首先要求项目经理和项目计划制定人员应当较好地掌握项目的环境条件，对各种条件进行深入的调查落实并做出有根据的预测，据以制定实施方案，适当留有余地，以使编制的项目计划切实而可行。
其次就是要使这种计划能够得到贯彻执行，因为再好的计划，如果不能认真执行，也不过是毫无意义的一纸空文。
根据各方面的经验，实行各种不同形式的责、权、利机制是保证计划实现的关键。
软件项目管理原则是什么？
软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。
我们中的大多数项目管理人员在其个人简历中纷纷写到：＂拥有多年的丰富的项目管理经验＂，但在实际开发中，＂丰富的＂管理经验变成了软件开发人员可怕的梦魇。
一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于＂无间＂（十八层地狱）。
一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。
但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。
此外还有一次，笔者在求职时，招聘公司的技术主管（40-50岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。
殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。
如此这样形式主义的公司，不呆也罢。
记得一个格言曾经说过＂人类最愚蠢的行为在于忘记常识＂。
另外一句较为相仿的格言则是＂不知道历史的人必然会重蹈覆。
作为项目管理来说亦为同样的道理。
很可惜，我们中的大多数管理者口口声声＂软件工程＂，工作时＂用程序代替用户需求＂，极具政客的嘴脸。
其结果必然如目前媒体＂程序员生存状况＂所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。
如何改善我们的软件开发管理，一条便捷之道便是＂尊重常识，尊重历史经验教训＂。
在软件项目管理中，有许多的原则和经验可以供我们借鉴。
一、计划原则 没有计划，你无从知道什么时候控制和变更。
制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。
计划能够告诉你什么时候应该做什么。
没有计划，你无从知道自己需要做什么。
不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。
由于没有计划或是计划太粗糙、不切实际，很多项目13甚至12的时间花在返工上面。
因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。
试想一下，制定一个周密合理的计划需要耗费这么多的时间吗？需要付出项目失败的代价吗？还有很多项目管理人员常常错误认为＂变化比计划快＂，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清？混沌＂状态。
此外，对于开发人员来说，＂目标导向（Ojective Oiented）＂是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。
因为近期目标总是比远期目标来说更容易看到和达到。
为此，制定一个计划吧，让它符合目标导向（通过各个具体任务计划促使项目总计划的达成）。
二、Books原则 向一个已经滞后的项目添加人员，可能会使项目更加滞后。
因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。
工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。
同时工作成本却不断的向上攀升。
不过就目前来说，项目管理人员丝毫不会理会这一点，＂人多力量大＂也许更能引人入胜。
不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性 所致。
为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。
现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。
三、验收标准原则 我们在进行某项任务，往往会为以何种结果为宜而感到困惑。
不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。
这是由于没有验收标准而导致的情景。
因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。
在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。
作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。
软件开发方法？
常见的软件开发方法有结构化方法、Jackson方法、维也纳开发方法（VDM）和面向对象的开发方法。
1.结构化方法： 指导思想：自顶向下，逐步求精； 基本原则：功能的分析与抽象。
优点： 1、 适用于数据处理领域的问题； 2、支持工具较多，发展成熟。
缺点： 1、不适应规模大的项目； 2、不适应特别复杂的项目； 3、难于解决软件重用的问题； 4、难于适应需求变化的问题； 5、难于彻底解决维护问题。
2.Jackson方法：这是一种面向数据结构的方法 过程：JSP—>JSD JSP方法： 1、以数据结构为驱动； 2、首先描述问题的输入，输出数据结构，分析其对应性，然后退出相应的程序结构，从而给出问题的软件过程描述。
JSD方法： 1、以事件作为驱动； 2、首先建立现实世界的模型，再确定系统的功能需求，对需求的描述特别强调了操作之间的时序性。
3.维也纳开发方法（VDM）：这是一种形式化的开发方法，是一个基于模型的方法。
主要思想：将软件系统当做模型来给予描述，具体说是把软件的输入，输出看做模型对象，而这些对象在计算机中的状态可看做为该模型在对象上的操作。
借助工具：描述工具语言Meta-IV。
4.面向对象的开发方法： 定义：以对象作为最基本的元素，是分析问题，解决问题的核心。
对象：具体的事物，事件，概念和规则。
基本点：尽可能按照人类认识世界的方法和思维方法来分析和解决问题。
...
进行软件研发人员考核的基本原则有哪些？
◆要体现公司的价值观 公司的价值观体现了公司认可什么类型的人员？要挽留哪些人？提倡做什么？对这些人员的认可可以通过具体的考核办法落实下来。
比如企业鼓励在某一个业务领域内积累丰富的领域经验，鼓励在某个技术方向上进行深入钻研等，对于提倡的这些行为，要有具体的奖励措施。
所以在定义考核办法时，需要首先考虑清楚要体现企业的哪些价值观。
◆要体现多劳多得，质与量并重 不能让那些完成了大量艰苦工作的人员吃亏，否则就会打击真正努力工作的人员的积极性。
多劳多得原则的实现，基于对工作量的计算。
规范的管理都是“以人为本、以过程为核心、以度量为基础”的。
要做到多劳多得就需要做好对工作量的度量，如果仅仅注重工作量而不关注工作质量，显然是不对的，而对于质量的考核，可以通过多个渠道来获得数据，如发现的缺陷个数、客户的反馈等等。
当然多劳多得的前提是团队的目标达成了，如果目标未完成，多劳未必多得。
◆要鼓励创新与规范管理 管理与创新是软件企业发展的2个轮子，通过规范管理可以确保企业的常规发展，[考试大提供]通过创新实现企业的跳跃式发展，管理为创新提供了转化为生产力的基础，创新可以快速地提高企业的竞争能力，因此在考核办法中要体现出来对这2者的认可。
有的企业设立了创新基金，专门用来奖励那些技术创新、管理创新等，有的企业在研发人员的考核指标中加入了对过程改进工作的支持等指标。
◆要鼓励技术复用 成功的软件企业必须在人员、技术、过程三个方面加大投入。
软件复用是目前软件公司提高软件生产率的最有效的手段之一，为了在企业内建立组织级的技术复用体系，首先就要鼓励大家主动去提取可复用的各种构件，主动贡献可复用的构件。
对于这种提取可复用构件的行为，应根据其可能带来的收益，适当给予奖励。
◆要因时而变，但要尽可能保持连续性 考核办法的制定都有一定的针对性，具有一定时限性，随着公司内外部环境的变化，随着公司文化的逐步稳定，对考核办法要逐步调整，在改变考核办法时，要注意保持考核办法的连续性，不要变化太大，否则就会让被考核人无所适从，产生观望的心态，或者在研究考核办法上花费很多时间，造成不必要的生产效率的下降。
◆要量化与非量化结合 如果没有量化的考核指标，全靠非量化的指标，对于开发人员来讲，很难体现多劳多得的原则，很容易走向“吃大锅饭”的模式，无法调动开发人员的积极性。
如果全量化也很难，在开发过程中，有很多工作难以量化，比如需求开发的工作，就很难定量的计算工作量。
因此在考核时，在尽可能量化的基础上，也允许有一些非量化的指标的存在。
至于2者的比重，可以根据当前企业的管理水平来确定。
对于管理比较规范的企业，成熟度比较高的企业，可以采用量化的指标多一些，量化的比重大一些。
◆要区分不同的岗位，不能一刀切 对于项目经理、需求分析人员、设计人员、程序员、测试人员、质量管理人员等，工作性质、能力要求、绩效表现的特征都有比较大的差别，因此要区别对待。
这样便于体现考核办法的内部公平性与外部公平性。
比如对于质量管理人员，大部分是日常的事务性的工作，其工作业绩的体现是长期的，他们的工作重心是预防缺陷的产生，采用量化的数据就比较困难，可以考虑采用改进率等指标来考核，而程序员的主要工作是实现设计，[考试大收集]任务的规模与他们的工作效率、质量是可以量化的，这2种类型的考核办法就应该是不同的。
◆要保证被考核人的及时知情权 事先要将考核办法告知被考核人，考核结果要及时通知被考核人。
考核的目的是为了发现改进工作业绩的方法，激励员工更加努力地工作，考核办法也代表了公司的价值观，因此要让被考核人对考核办法很清楚，让他们知道什么是应该努力去做好的，这样才能起到激励作用。
考核的结果应及时通知被考核人，这样能够给他们一个及时的肯定或者否定的刺激信号。
◆不以被考核人自己提供的数据为考核依据 如果以被考核人自己提供的数据作为考核依据，则会造成数据的失真。
在软件企业中推行开发人员的个人日志时，遇到的最大的问题就是日志的失真问题，为什么呢？因为开发人员担心自己填写的日志会成为自己的考核依据，会成为评价自己的工作努力程度的依据，因此本能地会倾向于满负荷地填写自己的工作量。
◆考核指标要和被考核人直接相关，被考核人对考核指标的达成能发挥重要的作用 在很多软件公司中，经常发现员工的考核与公司的利润、部门的利润或者项目的利润挂钩，对于销售部门、事业部或者其他直接与市场相关部门，这种考核是有激励作用的，对于研发人员来讲，这种办法的激励作用就不那么明显了。
7个软件有哪些开发原则？
Matin Fowle在它的Refactoing一书中有很多用来处理代码重复，包括： 1. 同一个类的两个方法中有相同的表达式，使用Extact method，然后大家都调用该method; 2. 两个兄弟子类之间有相同的表达式，那么在这两个子类中使用Extact Method，接着使用pull up field，移到共同的超类 3. 如果结构相似而并非完全相同，用Extact method把相同部分和不同部分分开。
然后使用Fom Template method. 4. 如果方法使用不同的算法做相同的事情，那么使用sustitute algoithm 5. 如果在两个不相干的类中有重复代码，那么在一个类中使用Extact class，然后在其他类中使用该class对象作为元素。
等等。
重复代码需要efactoing是毫无疑问的，关键在于，你如何找到重复代码，如果所有的重复代码都是死板的重复，那问题是很容易解决的。
但是软件开发的复杂因素可能往往使重复代码表现为相似性而并非完全的重复。
这些相似性可能并非一眼就能看出来。
而是需要经过其它的Refactoy步骤和一定的先见之明。
另一个问题就是排除重复代码的粒度，只有大段的重复代码有价值去排除，还是即使是小小的 2、3句重复代码就应该去排除。
重复代码排除的基本方法是建立自己单独的方法，如果系统中许许多多的方法都很小，方法之间相互调用的开销就会增加，它同时也增加了维护的开销。
但是，这些开销是值得的。
方法是覆盖的最小粒度，能够被覆盖的粒度越小，能够重用的范围和成都就愈广。
但在这个问题上也不要走极端，只有当一个方法实现一个具体的可以用Intent Revealing Name（揭示意图的名字）命名时，一段代码才值得称为一个方法，而不是考虑其代码的多少。
Matin Fowle在他的efactoing中描述了很多这样的例子，Kent Beck则在Smalltalk Best Pactice Patten中更基础地揭示了隐含在这些efactoing下的意图。
下面是一个实际的例子，来自于Matin Fowle在ACM上的设计专栏： class Invoice... Sting asciiStatement() { StingBuffeesult = new StingBuffe(); esult.append(“Bill fo “ + custome + “\n”); Iteato it = items.iteato(); while(it.hasNext()) { LineItem each = (LineItem) it.next(); esult.append(“\t” + each.poduct() + “\t\t” + each.amount() + “\n”); } esult.append(“total owed:” + total + “\n”); etun esult.toSting(); } Sting htmlStatement() { StingBuffeesult = new StingBuffe(); esult.append(“ Bill fo ” + custome + “ ”); esult.append(“”); Iteato it = items.iteato(); while(it.hasNext()) { LineItem each = (LineItem) it.next(); esult.append(“ ” + each.poduct() + “ ” + each.amount() + “ ”); }
在软件的开发过程中,必须遵循的原则是
&nsp；这就要看你用Java来开发什么了，适合开发JAVA的有Eclipse, JCeato,JBuilde,NetBeans等很多。
相对来说，Eclipse较好一些，因为它不仅是免费开源的，而且适用面也更广，一般企业做Java开发都是用它和MyEclipse（收费的）结合做的。
JCeato主要用来学习JAVA的语法，开发项目的话强烈建议不要用JCeato。
JBuilde和NetBeans比较慢，不过做Swing（图形开发）的话比Eclipse要好些。
软件开发方法？
常见的软件开发方法有结构化方法、Jackson方法、维也纳开发方法（VDM）和面向对象的开发方法。
1.结构化方法：指导思想：自顶向下，逐步求精；基本原则：功能的分析与抽象。
优点：1、 适用于数据处理领域的问题；2、支持工具较多，发展成熟。
缺点：1、不适应规模大的项目；2、不适应特别复杂的项目；3、难于解决软件重用的问题；4、难于适应需求变化的问题；5、难于彻底解决维护问题。
2.Jackson方法：这是一种面向数据结构的方法过程：JSP—>JSDJSP方法：1、以数据结构为驱动；2、首先描述问题的输入，输出数据结构，分析其对应性，然后退出相应的程序结构，从而给出问题的软件过程描述。
JSD方法：1、以事件作为驱动；2、首先建立现实世界的模型，再确定系统的功能需求，对需求的描述特别强调了操作之间的时序性。
3.维也纳开发方法（VDM）：这是一种形式化的开发方法，是一个基于模型的方法。
主要思想：将软件系统当做模型来给予描述，具体说是把软件的输入，输出看做模型对象，而这些对象在计算机中的状态可看做为该模型在对象上的操作。
借助工具：描述工具语言Meta-IV。
4.面向对象的开发方法：定义：以对象作为最基本的元素，是分析问题，解决问题的核心。
对象：具体的事物，事件，概念和规则。
基本点：尽可能按照人类认识世界的方法和思维方法来分析和解决问题。
