软件开发_软件开发工具 - CSDN
软件开发 订阅
软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。软件一般是用某种程序设计语言来实现的。通常采用软件开发工具可以进行开发。软件分为系统软件和应用软件,并不只是包括可以在计算机上运行的程序,与这些程序相关的文件一般也被认为是软件的一部分。 软件设计思路和方法的一般过程,包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。 展开全文
软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。软件一般是用某种程序设计语言来实现的。通常采用软件开发工具可以进行开发。软件分为系统软件和应用软件,并不只是包括可以在计算机上运行的程序,与这些程序相关的文件一般也被认为是软件的一部分。 软件设计思路和方法的一般过程,包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。
信息
中文名
软件开发
外文名
Software development
含    义
根据用户需求编写指定软件的行为
软件开发阶段划分
对所要解决的问题进行总体定义,包括了解用户的要求及现实环境,从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性,编写可行性研究报告,探讨解决问题的方案,并对可供使用的资源(如计算机硬件、系统软件、人力等)成本,可取得的效益和开发进度作出估计,制订完成开发任务的实施计划。软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求,设计建立相应的软件系统的体系结构,并将整个系统分解成若干个子系统或模块,定义子系统或模块间的接口关系,对各子系统进行具体设计定义,编写软件概要设计和详细设计说明书,数据库或数据结构设计说明书,组装测试计划。在任何软件或系统开发的初始阶段必须先完全掌握用户需求,以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制优先加以定位。系统工程师最终将据此完成设计方案,在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据,也可以是可组合、可分解和可更换的功能单元。模块,然后进行模块设计。概要设计就是结构设计,其主要目标就是给出软件的模块结构,用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构,次要任务就是设计数据库,常用方法还是结构化程序设计方法。软件编码是指把软件设计转换成计算机可以接受的程序,即写成以某一程序设计语言表示的“源程序清单”。充分了解软件开发语言、工具的特性和编程风格,有助于开发工具的选择以及保证软件产品的开发质量。当前软件开发中除在专用场合,已经很少使用二十世纪80年代的高级语言了,取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体,大大提高了开发的速度。软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例(测试数据与功能和预期的输出结果组成了测试用例)。如何才能设计出一套出色的测试用例,关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序,依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述,发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。维护是指在已完成对软件的研制(分析、设计、编码和测试)工作并交付使用以后,对软件产品所进行的一些软件工程的活动。即根据软件运行的情况,对软件进行适当修改,以适应新的要求,以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。一个中等规模的软件,如果研制阶段需要一年至二年的时间,在它投入使用以后,其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间,人们几乎需要着手解决研制阶段所遇到的各种问题,同时还要解决某些维护工作本身特有的问题。做好软件维护工作,不仅能排除障碍,使软件能正常工作,而且还可以使它扩展功能,提高性能,为用户带来明显的经济效益。然而遗憾的是,对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上,和软件研制工作相比,软件维护的工作量和成本都要大得多。在实际开发过程中,软件开发并不是从第一步进行到最后一步,而是在任何阶段,在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计,用户可能会提出一些需要来修改需求说明书等。
收起全文
精华内容
参与话题
  • 一个软件完整的开发流程介绍

    万次阅读 多人点赞 2018-06-21 14:21:02
    刚开始写博文的时候就应该将这个文章更新一下,虽然不是什么大牛,但是对于软件开发流程还是比较了解的,毕竟大大小小做过了好几个项目了,今天就大概的说一下,用我做过的一个项目来说吧,写的不好的,请多多见谅...

    刚开始写博文的时候就应该将这个文章更新一下,虽然不是什么大牛,但是对于软件的开发流程还是比较了解的,毕竟大大小小做过了好几个项目了,今天就大概的说一下,用我做过的一个项目来说吧,写的不好的,请多多见谅,毕竟小生不才。

    开发流程百度的解释是:


    不是我懒得写,而是觉得写出来也不是自己的,还不如直接告诉你们我是百度的概念...但是下面的我们就不要百度了,因为百度说的太专业,让你看了很烦,最起码我是很烦(都是些什么玩意).


    进入正题

    我们分公司性质来说一个软件的开发流程,

    软件公司和非软件公司

    非软件公司

    需求分析-概要设计-程序编码-程序测试-软件交付-客户验收-码农维护

    软件公司

    需求分析-概要设计-详细设计-程序编码-程序测试-软件交付-客户验收-码农维护

    我们一步一步的说:

    需求分析

    一个软件没有出现之前,只是有一部分人有一个想法,我需要一个这样的东西(想要一个孩子了)用来管理我的什么什么,这个时候一个想法出现了,就会有这个需求,他会找软件公司需求分析师来商量,这个时候一个软件就怀孕了,相当于开始发育了.需求分析是听完要求以后会将大概的功能描述一下,用Word或者Axure画出一个简单的Demo给用户看,经过几次确认以后需求分析师会最后确认功能是不是完善的,确认了以后进行我们的下一步,概要设计

    概要设计

    这个功能主要是干嘛的呢?很多的公司觉得没必要,其实是很有必要的,这个就是相当于先规划一下怎么平安度过怀孕期,对于软件来说就是软件的处理逻辑,大概的一个流程是怎么走的,大概需要哪些模块,怎么运行,需要大概多少接口,后期怎么维护等问题,做这些干呢吗?为了下一步-详细设计

    详细设计

    有人说,详细设计是很麻烦的一步,其实不是很麻烦的一步,我觉得是最难的一步,详细设计主要是用来确认细节的,接口的名字啊,控制器的名字啊,多少个控制器,谁来调用谁,这个不可以有错,因为后期码农是需要看这个开发的,你怎么起名字,他们就怎么写,所以这里出错也就意味着编码的时候也会错,最后会有一份详细设计书出现,这个就是告诉孕妇具体吃什么,怎么吃,多少量。

    码农编码

    很多人觉得这个就是搬砖,看着设计书就直接写就可以了,理论是这样的,但是为什么还有很多的bug出现呢?很大一部分原因并不是设计的原因(当然也有可能),很大原因是不规范造成的,还有就是是不是一个项目组的人可以协作处理代码,怎么做可可以提高编码的效率,这些问题都是在编码的时候出现的问题。这个是相当于孕妇实施那一套套餐的时候具体是不是按规范来吃的。

    程序测试

    这一步是里面很重要的一步,测试,我们不可能说写好直接就给用户用了,这个是不现实的,我们需要做的是先给测试部门进行系统的测试,当然这个测试不是按照用户的想法来的,他们会很暴力,举个栗子,一个按钮,正常的用户使用的时候会直接点击一次,看到效果就可以了,但是测试的时候不是,他们会疯狂的点击,知道他们觉得这个世界上不会有人比他们暴力的时候他们会停止,当然这是一个好的测试人员,很多的测试不会是这样的,他们觉得正常使用没问题就是没事的,其实一个软件好不好,很大一部分在于测试人员的测试力度。最后写一份测试报告就可以了。

    软件交付

    测试结束以后没有任何的问题的话,就可以写安装手册了,这个其实就是用户使用指南。

    客户验收

    交付后客户简单的测试以后觉得是和自己想的一样的,就收货,交钱.

    码农维护

    是不是验收以后就没事了呢?当然不是,一个软件很多时候是在用一段时间以后才会出问题的,所以会一直需要人来维护他们,当然不是说只是出问题才会维护的,主要的原因是软件会根据不同的需要更改功能,这样的过程也是维护的过程,QQ已经更新多少代了,是不是,这也是一个维护的过程。

    项目重构

    这个是一个项目如果出现了新的技术,功能没有改变的时候,为了用户体验,例如之前是SSH写的,但是运行的速度很低,用SpringBoot,大家都在用,用户反映很好,那么这个时候就需要项目重构了,用新的技术将之前的功能重新实现。

    基本那就是这些了,另外细心的人也看到了非软件公司是没有详细设计的,这个解释一下,为什么呢?很简单,其实详细设计是和耗费时间的,非软件公司的人不会花费这个时间在设计上,他们就是直接告诉你需求,码农只需要直接编码就可以了,一般这样的对你用什么技术,什么框架是没有要求的。




    展开全文
  • 2011年,马克·安德列森(Marc Andreessen)写了一篇文章,预言“软件吞噬世界”。观点主要有两个:第一,许多传统业务正在被软件公司所取代;第二,所有其他公司...
        

    640?wx_fmt=png

    2011年,马克·安德列森(Marc Andreessen)写了一篇文章,预言“软件吞噬世界”。观点主要有两个:第一,许多传统业务正在被软件公司所取代;第二,所有其他公司都发现,他们所提供的价值越来越多地来自软件系统。


    在安德森撰写这篇文章时,市值最大的10家公司中,没有一家是从事软件驱动业务的。如今,10家最大的公司中有6家主要由软件驱动,而其他4家也已经准备好了转型。


    Stack Overflow和LinkedIn列出非技术公司的软件工程招聘广告超过了科技行业本身。这是经济发展中的一个重大转变,表明公司正在加强他们的软件工程实践。


    会计和软件,哪一个对公司更重要?本文没有答案。但是现在许多不认为自己是软件公司的公司也开始发现:软件系统是他们运营的一个关键组成部分。


    640?wx_fmt=png


    如果CEO和各级管理人员不了解软件,那么他们将是可有可无的。这要么会限制他们的职业发展,要么会对公司业绩产生负面影响。不管怎样,不了解软件都注定要失败。(据Gartner预测,到2020年,有50%的首席信息官(CIO)将被取代,因为他们没有变革公司的能力。)


    本文列出了管理者应该知道的10个常识:

    1. 软件不是魔术

    2. 软件永远不会“完成”

    3. 软件开发是团队作战,没有人能做所有事情

    4. 设计不是外观,而是工作原理

    5. 安全是每个人的责任

    6. feature大小并不能预测开发时间

    7. 伟大来自于成千上万的小进步

    8. 技术债很讨厌,但不可避免

    9. 软件不会自己运行(软件需要运维)

    10. 复杂的系统需要DevOps才能良好运行


    关于软件,本文认为这是所有管理者都需要知道的10件最重要的事情:


    1. 软件不是魔术


    软件不是魔术。虽然它看起来像魔术,或者是魔法,但它不是魔法。每一个元素都是由人设计的,都有其数学基础,或者是可以用人类语言解释的过程。


    640?wx_fmt=jpeg


    与魔术不同,软件不是凭空变出来的。它需要设计、构建和维护。就像房子有多种系统一起工作(地基、结构、管道、房间、家具等等)那样,软件系统也需要许多层和子系统来创建整个系统。它可以设计得很好,也可以设计得很差,而且快速的设计很少能持久。


    如果人们不能用语言来描述它会做什么(包括想要的结果和如何实现),那么计算机也无法做到。“how”被称为算法,这并不神奇。


    机器学习和其他人工智能技术也并不神奇。机器学习是基于数据的预测,而不是显式的规则或指令。它一般是用线性代数来做的。如果有100万张已知的香蕉照片和100万张没有香蕉的照片,一个训练有素的机器学习系统看一张新照片,会根据它从之前的照片中学到的知识告诉你它看起来像第一组还是第二组,这不是魔术。使用机器学习根据过去的招聘决定对简历进行排序,即使没有任何故意的偏见,也可能会放大经验主义的招聘历史。


    2. 软件永远不会“完成”


    软件永远不会“完成”,软件是一个迭代的过程,在其生命周期中包含许多修订和更新。我们的工作是创造一个能认识到这一点的环境。


    同样,我们从来没有期望市场营销和客户获取是“完成的”,它们也是迭代过程。在每个迭代中,随着我们不断地为业务交付价值,我们也不断地学习和成长。即使已经做了一些成功的发布,我们从来没有打算“停止”做这些事情。


    640?wx_fmt=jpeg


    如果软件可以在一个版本中完成就好了,但这不是现实。需求文档充满了模糊性,软件的第一个版本充满了“哦,那是我写的,但不是我的意思”的场景。最好的软件能激发新的想法和功能需求,看到新的销售管理系统更加高效,就会激发出更高的效率。世界在变化,竞争对手提供了新的功能,人们就有了新的想法。另外,总是有一些bug需要修复:可能是在代码中,也可能是在构建代码的底层软件框架和系统中。某些软件可能是完美的,但可以确信的是,随着时间的推移,人们会发现它所构建的平台存在各种漏洞。


    我们的工作就是让一个组织能够认识到这一点。


    认识到这一点的方法是建立一个有信心定期发布新版本的组织。当完全自动化测试和其他工程规范就位时,我们就建立了信心。这种信心创造了一种能力,可以避免过长的发布周期,而是每季度、每月甚至每周发布高质量的软件。特定的频率并不重要,但是信心很重要,自信能够带来更快的创新。


    3.软件开发是团队作战,没有人能做所有事情


    软件开发是团队作战,开发人员既不是产品经理,也不是UX(用户体验)设计师,也不是质量工程师、分析师、安全专家、技术作家或运营工程师。组织需要所有角色。


    没有哪个管理者会建议每个销售(sale)人员都做营销(marketing)及PR,否则就解雇销售团队(因为营销人员了解产品,也能做销售)。营销和销售是相关的,但又是不同的。因此,两者之间存在着分工。


    同样,开发团队需要独立的人员来收集需求、质量保证和测试、代码编写等等。


    640?wx_fmt=jpeg


    一个开发人员可以“做所有事情”的神话,称为“全栈开发人员”或“10x工程师”,这一般只存在于小公司。是的,一个非常小的公司可能一个人同时做营销和销售,但你可能不会加入这样的小公司。


    不要用自己的兴趣去挑战别人吃饭的专业。一个小孩“擅长Facebook”并不意味着他或她会成为下一个扎克伯格;一个小孩对工程学很感兴趣并不意味着他或她可以能够使用微积分;一个小孩能够自己做了一个网站并不意味着这个网站每小时可以处理数十亿的金融交易。


    4. 设计不是外观,而是工作原理


    史蒂夫·乔布斯有句名言:”设计不只是外表和感觉。设计就是工作原理。“ UX设计师不会坐下来决定菜单的颜色,或者决定按钮是圆形还是方形,他们决定工作流和交互是什么。


    640?wx_fmt=jpeg


    用户会看到一个有三个选项的屏幕,还是一个屏幕只显示一个选项?这个设计决定需要心理学、对用户的同理心,以及测试、测试、再测试。


    UX设计的最大挑战之一是,一旦你熟悉了系统,就失去了预测新用户的能力。设计该系统的人在预测新用户的需求时将自动被取消资格。UX可能很漂亮、优雅,可以与一件艺术品相媲美,但是请UX设计师将背景更改为帆船的图片是没有帮助的。


    我们的工作是信任测试数据而不是主观臆测,创建一个环境,在产品发布之前计划进行多次修订,并期望在产品发布之后进行进一步的改进。不要将UX设计人员与图形设计人员混淆。让UX计师设计公司节日贺卡和让技术作家写公司通讯是一样的失礼行为,这些是不同的技能。


    5. 安全是每个人的责任


    不管知不知道,无论愿不愿意,我们都是从事安全行业的。所有软件都有安全需求和潜在的安全漏洞。开发软件所涉及的系统也有安全需求和漏洞。虽然防火墙和入侵检测等安全的基础设施组件是必要的,但它们还不够:还必须使用内置的安全控制来设计、实现和维护软件平台。安全既是好的技术,也是好的流程。


    640?wx_fmt=jpeg


    如果认为我们不是被攻击的目标,那就错了。所有的计算机系统都是被攻击的目标,因为攻击不仅是为了其中的信息,而仅仅是它是一台计算机这样的一个事实。例如,一个没有价值信息的系统是网络攻击目标,因为它可以被用来转发对其他计算机的攻击,或挖掘比特币,或存储他人的盗版视频。


    安全不是打开/关闭这样按钮,有许多灰色地带。安全性最好从一开始考虑。事后的亡羊补牢是昂贵的,而且往往是无效的。我们不会先造一艘船,然后再“添加”一种让它漂浮的功能。同样,也无法先构建一个系统,然后按下“具有安全性”按钮就安全了。


    安全是关于风险和对风险的容忍度。对两个节点之间的通信进行加密并不能保证它的安全性,但它提高了安全性,只有超级算力才有可能破解密码。在一个领域降低风险对其他领域没有帮助。保护网络并不能防止物理安全问题。一个人撑开一扇门,其他人就能偷走你的备份磁带。


    正如吉恩·斯帕福德(Gene Spafford)的一句名言:”唯一真正安全的系统,是一个关了电、浇铸在混凝土里、由全副武装的警卫把守在绝缘房间里的系统——即便如此,我还是心存疑虑。“


    遵守NIST CSF(国家标准与技术网络安全框架学会)、PCI DSS(支付卡行业数据安全标准)和SOC 2(服务组织控制报告)等安全标准可以量化风险,如果做得合适,还可以降低风险。这些标准并不能保证绝对安全,绝对安全是不存在的。更重要的是,它们为如何负责任地应对和报告不可避免的安全漏洞提供了指导。诚实、直率、公开是良好的建议。


    软件,如果不管它,就像面包一样变得陈旧。我们的工作是平衡安全妄想与现实,并适当预算时间和资源。


    6. feature大小并不能预测开发时间


    feature大小(用户感知到的)与创建feature所需的时间完全无关。小feature可能需要几天或几年的时间,大feature(用户感知到的)也可能需要几天或几年的时间。


    640?wx_fmt=jpeg


    我们的工作是创建并支持一个软件开发过程,该过程接受这个事实,并且不是拍脑袋评估工程量。工作量评估本身可能需要令人惊讶的很长时间。


    鼓励通过沟通来解决工作量评估的问题。工程师可能会给出一个令人惊讶的很长时间的工作估算,但是也会提出对需求进行更改,从而大大缩短时间。记住工作量评估要包括测试、培训、部署和意外的假期(例如病假)。


    在没有与工程部门协商工作量的情况下,永远不要承诺某个feature。这并不是我们在公司的权力标志,这需要的是一个专业流程,在这个流程中,开发人员的请求得到认真对待,评估工作量,并按时交付(或出于诚实的原因延期)。


    7. 伟大来自于成千上万的小进步


    伟大来自于在很长一段时间内所做的成千上万,也许是数百万的小进步(变更)。如果变更的效果都被测量是负面的,那么变更将被回滚。


    谷歌也不是一天建成的。谷歌的搜索引擎是数百万个人改进的结果。搜索质量小组每周开会一次,工程师们走上讲台,提出他们的修改建议。他们展示了在模拟的环境中会有多大的改进,委员会进行辩论并投票表决。几周后,将对测量结果进行评审,并决定保留或回滚更改。


    谷歌搜索是迭代开发战胜“数据大爆炸”思维的胜利。谁都不可能在一开始做出一个好的搜索引擎。只有在好莱坞电影中,一个聪明的极客才会想出一个惊人的新点子,并且第一次就能完美地实现它。在现实世界中,一夜成名需要数年的时间。


    无论试图实现的目标是一个为客户提供更好服务的系统,还是一个更高效、错误更少的系统,还是一个运行更顺畅的系统,都是如此。


    我们的工作是要求系统的设计能够容易拥抱新的变化,并定义相关的KPI(关键性能指标),这些KPI可以在更改之前和之后方便地进行度量。最重要的是,必须有一个流程来检查结果,并决定保留或回滚变更。回滚不应被视为失败或受到惩罚。从每次回滚中学到的与在每次保留的更改中学到的一样有价值。


    640?wx_fmt=jpeg


    托马斯·爱迪生声称在发明灯泡的过程中测试了1000根灯丝。当一位记者问他:”失败1000次是什么感受?“他回答说:”我没有失败1000次。灯泡是一项有1000个步骤的发明。”


    8. 技术债很讨厌,但不可避免


    技术债务是将来需要做的工作,因为我们现在选择了一个更简单的解决方案,而不是使用一个需要更长时间的更好解决方案。任何合理规模的软件项目都有技术债务。技术债务让所有的进步都变得更慢,越忽视它,它就越像滚雪球一样越滚越大。


    有金融背景的管理者听到“债务”时,会认为这是一种未来会有回报的投资。技术债务恰恰相反,它是有毒和痛苦的,并且是一个定时炸弹。


    1972年,Fram为它的滤油器做了一个电视广告,在广告中,一位汽车机械师解释说,一位顾客为了节省4美元而不更换滤油器,后来,这位顾客不得不花200美元更换一个昂贵的主轴承。汽车机械师总结说:“你可以现在付给我钱,也可以以后付。”


    640?wx_fmt=jpeg


    有一个软件项目,其中有一个子系统与供应商通信。最初系统只与一个供应商通信,所以非常简单。然后又接了一个,然后另一个。有些功能必须实现三次,每个供应商一次,这是不可持续的。当要求支持第四个供应商时,开发人员表示反对。是的,他们可以在大约一个月的时间里把它移植上去,但是软件架构开始吱吱作响,就像飓风中的老房子一样。这些权宜之计积累了大量的技术债务。


    开发人员的建议是花两个月的时间重构供应商架构,使其成为一个插件系统。然后,新的供应商可以在一周内而不是一个月内支持接入。


    管理者们并不高兴。为什么下一个供应商需要两个多月的时间来支持,而之前的供应商是在一个月内支持的呢?花两个月的时间来偿还技术债务将使未来的支持更快,代码更稳定,并使添加新feature更容易。很难衡量确切的好处。


    “你可以现在付给我,也可以以后再付给我"。


    我们的工作是分期偿还技术债务。失控的技术债务降低了添加其他feature的能力,并导致软件系统不稳定。偿还技术债务应该与业务目标挂钩,类似于非功能需求。


    9. 软件不会自己运行(软件需要运维)


    虽然供应商和开发人员可能会试图告诉你不同的情况,但是软件并不会自己运行。任何基于软件的系统(特别是网站和web应用程序)都需要运维人员和运维流程。否则,软件就像一本合上的书,必须有人打开它,管理它,以及照顾它的需求。


    640?wx_fmt=png


    运维比软件开发本身更重要。代码只写一次,但运行可能会是数百万次。因此,粗略地衡量一下,运维的重要性是否要高出几百万倍呢?


    我们的工作就是期望运维成为任何软件系统的一部分。它必须像其他任何项目一样被计划、预算、管理和有效地运行。


    运维功能(通常称为非功能需求)对用户是不可见的,除非作为二级需求。数据备份是非功能需求中一个很好的例子。没有用户请求数据备份,但是,用户确实要求恢复已删除的数据。遗憾的是,没有备份就没有恢复。恢复是功能需求,备份是一种运维(非功能)需求。


    让软件服务易于维护或高效运行的功能需求从来不会被用户提出来。然而,他们确实享受着一个低成本、高可靠的系统所带来的好处。客户会离开那些不靠谱的网站,再也不会回来。


    持续改进的需求不仅包括新功能需求,还应该包括新的非功能性需求。因此,我们的工作不仅是为客户提出的功能需求分配资源,还要为运维需求分配资源。在两种相互竞争的需求之间取得平衡是困难的。


    但是,一个成功的产品是业务需求和运维需求的权衡结果。


    10. 复杂的系统需要DevOps才能良好运行


    复杂的系统最好通过DevOps进行改进。DevOps有很多定义,但是DevOps通常看作是通过快速迭代加速交付价值(feature、bug修复、流程改进等等)。要做到这一点,每个相关人员都必须参与。也就是说,他们必须跨职能团队进行协作。DevOps这个名字来自于移除开发人员和运维(IT)之间的隔阂,这对于实现快速的发布是绝对必要的。然而,优秀的DevOps环境将其扩展到跨所有职能团队的端到端工作。


    640?wx_fmt=jpeg


    DevOps被误解为开发人员来做运维。这种“构建它,运行它”的策略是跨职能团队工作(消除隔阂)的一种方法,但它不是唯一的方法。


    一个复杂的系统需要三件事:良好的流程、所有相关人员的良好沟通以及尝试新事物的能力。


    结论


    软件正在吞噬世界。本文总结了软件以及软件工程的10个箴言,希望管理者及相关从业者理解其重要性并从中受益。


    原文:https://queue.acm.org/detail.cfm?id=3325792

    作者:Thomas A. Limoncelli


    关联阅读:

    软件架构的10个常见模式

    面向数据架构的云演变

    从应用架构看大数据

    再谈<全栈架构师> 一文

    CAP理论与分布式系统设计

    老码农看到的技术债务

    面向全栈的技术管理

    老曹眼中研发管理二三事

    全栈的技术栈设想

    DevOps 全栈必备双刃剑

    移动产品的指标初探


    展开全文
  • 几种常见的软件开发模型

    万次阅读 2017-01-02 19:22:03
    软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确...

    软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。对于不同的软件系统,可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等,以及允许采用不同的软件工具和不同的软件工程环境。

    软件工程的主要环节包括人员管理、项目管理、需求分析、系统设计、程序设计、测试、维护等,如图所示。软件开发模型是对软件过程的建模,即用一定的流程将各个环节连接起来,并可用规范的方式操作全过程,好比工厂的生产线。


    几种常见的软件开发模型


     

    ---------------------------------------------------------------------------------------------------------

    最早出现的软件开发模型最早出现的软件开发模型是1970WRoyce提出的瀑布模型。 该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。但计算拓广到统计分析、商业事务等领域时,大多数程序采用高级语言(FORTRANCOBOL)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的 需求等缺点。常见的软件开发模型还有演化模型、螺旋模型、喷泉模型、智能模型等。编辑本段典型的开发模型典型的开发模型有:

    1.边做边改模型(Build-and-Fix Model);

    2.瀑布模型(Waterfall Model);

    3.快速原型模型(Rapid Prototype Model);

    4.增量模型(演化模型)Incremental Model);

    5.螺旋模型(Spiral Model);

    6.喷泉模型(fountain model)

    7.智能模型(四代技术(4GL)

    8.混合模型(hybrid model);

    9.RUP模型;

       10.IPD模型 

     

    1. 边做边改模型(Build-and-Fix Model)

    遗憾的是,许多产品都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。

     

    在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。

    几种常见的软件开发模型

    这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:   

    1 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;

    2)忽略需求环节,给软件开发带来很大的风险;

    3)没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

    2. 瀑布模型Waterfall Model

    1970Winston Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

     

      

    几种常见的软件开发模型



    瀑布模型中,如图所示,将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

    在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。

    瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

    1 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;

    2 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;

    3 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

     

    我们应该认识到,"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的" 线性"问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线 性的方式来实现,否则干活就太累了。线性是一种简洁,简洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如增量模 型实质就是分段的线性模型,螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子。

     

    3. 快速原型模型Rapid Prototype Model

    快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

     

     

    显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。

     

    4. 增量模型Incremental Model

    又称演化模型。与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

    几种常见的软件开发模型

     

     

    增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:   

    1 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。  

    2 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。   

    在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。   

    例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。

     

    5.螺旋模型Spiral Model

    1988年,Barry Boehm正式发表了软件系统开发的"螺旋模型",它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。

    几种常见的软件开发模型

     

    如图所示,螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:   

    1 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;   

    2 风险分析:分析评估所选方案,考虑如何识别和消除风险;   

    3 实施工程:实施软件开发和验证;   

    4 客户评估:评价开发工作,提出修正建议,制定下一步计划。   

    螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:   

    1 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。   

    2 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。   

    3 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险。

    一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。

     

    6.喷泉模型fountain model(也称面向对象的生存期模型, OO模型)

      几种常见的软件开发模型

    喷泉模型与传统的结构化生存期比较,具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来,可以落在中间,也可以落在最底部。

     

    7.智能模型(四代技术(4GL)

     

    智能模型拥有一组工具(如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等),每个工具都能使开发人员在高层次上定义软件的某些特性,并把开发人员定义的这些软件自动地生成为源代码。   

    这种方法需要四代语言(4GL)的支持。4GL不同于三代语言,其主要特征是用户界面极端友好,即使没有受过训练的非专业程序员,也能用它编写程序;它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的 数据库和应用程序生成器。目前市场上流行的4GL(如Foxpro等)都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的 开发。

    几种常见的软件开发模型

     

    8.混合模型hybrid model

    过程开发模型又叫混合模型(hybrid model),或元模型(meta-model,把几种不同模型组合成一种混合模型,它允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)。实际上,一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。各种模型的比较每个软件开发组织应该选择适合于该组织的软件开发模型,并且应该随着当前正在开发的特定产品特性而变化,以减小所选模型的缺点,充分利用其优点,下表列出了几种常见模型的优缺点。各种模型的优点和缺点:        

    模型

    优点

    缺点

    瀑布模型

    文档驱动

    系统可能不满足客户的需求

    快速原型模型

    关注满足客户需求

    可能导致系统设计差、效率低,难于维护

    增量模型

    开发早期反馈及时,易于维护

    需要开放式体系结构,可能会设计差、效率低

    螺旋模型

    风险驱动

    风险分析人员需要有经验且经过充分训练

           

    9.RUP模型

         RUPRational Unified Process)模型是Rational公司提出的一套开发过程模型,它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程,它们具有相同的结构,即相同的流程构架。RUP 为在开发组织中分配任务和职责提供了一种规范方法,其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP具有两个轴,一个轴是时间轴,这是动态的。另一个轴是工作流轴,这是静态的。在时间轴上,RUP划分了四个阶段:初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上,RUP设计了六个核心工作流程和三个核心支撑工作流程,核心工作流轴包括:业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括:环境工作流、项目管理工作流和配置与变更管理工作流。RUP 汇集现代软件开发中多方面的最佳经验,并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型,它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂,因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。

    它具有如下特点:

    1)增量迭代,每次迭代都遵循瀑布模型能够在前期控制好和解决风险;

    2)模型的复杂化,需要项目管理者具有较强的管理能力。

     

    10.IPD模型

    IPDIntegrated Product Development)流程是由IBM提出来的一套集成产品开发流程,非常适合于复杂的大型开发项目,尤其涉及到软硬件结合的项目。

    IPD从整个产品角度出发,流程综合考虑了从系统工程、研发(硬件、软件、结构工业设计、测试、资料开发等)、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。

    IPD流程中总共划分了六个阶段(概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段),四个个决策评审点(概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点)以及六个技术评审点。

    IPD流程是一个阶段性模型,具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上,该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制,因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目,也不是非常适合使用该流程。

     

    参考:

    http://blog.csdn.net/zzzmmmkkk/article/details/4230709

    http://hi.baidu.com/xf_asp/item/2482e4df8e2df956d63aaef4

    http://hi.baidu.com/zifan/item/bd3c121625d6315f2b3e225e

    展开全文
  • 软件开发基本流程【一】

    万次阅读 多人点赞 2019-02-14 10:45:49
    它是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题,建立软件的逻辑模型,编写...

    分析 


    软件需求分析就是回答做什么的问题。它是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求 ,设计建立相应的软件系统的体系结构,并将整个系统分解成若干个子系统或模块,定义子系统或模块间的接口关系,对各子系统进行具体设计定义,编写软件概要设计和详细设计说明书,数据库或数据结构设计说明书,组装测试计划 。


    设计 


    软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据,也可以是可组合、可分解和可更换的功能单元。模块,然后进行模块设计。概要设计就是结构设计,其主要目标就是给出软件的模块结构,用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构,次要任务就是设计数据库,常用方法还是结构化程序设计方法。 


    编码 


    软件编码是指把软件设计转换成计算机可以接受的程序,即写成以某一程序设计语言表示的"源程序清单"。充分了解软件开发语言、工具的特性和编程风格,有助于开发工具的选择以及保证软件产品的开发质量。 
    当前软件开发中除在专用场合,已经很少使用二十世纪80年代的高级语言了,取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体,大大提高了开发的速度。 


    测试 


    软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例(测试数据和预期的输出结果组成了测试用例)。如何才能设计出一套出色的测试用例,关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序,依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述,发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。黑盒法。 


    维护 


    维护是指在已完成对软件的研制(分析、设计、编码和测试)工作并交付使用以后,对软件产品所进行的一些软件工程的活动。即根据软件运行的情况,对软件进行适当修改,以适应新的要求,以及纠正运行中发现的错误。编写软件问题报告、软件修改报告 。 
    一个中等规模的软件,如果研制阶段需要一年至二年的时间,在它投入使用以后,其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间,人们几乎需要着手解决研制阶段所遇到的各种问题,同时还要解决某些维护工作本身特有的问题。做好软件维护工作,不仅能排除障碍,使软件能正常工作,而且还可以使它扩展功能,提高性能,为用户带来明显的经济效益。然而遗憾的是,对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上,和软件研制工作相比,软件维护的工作量和成本都要大得多。


    在实际开发过程中,软件开发并不是从第一步进行到最后一步,而是在任何阶段,在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计,用户可能会提出一些需要来修改需求说明书等。

     

    1、项目设计 


    项目设计的主导思想,我觉得可以理解为两种,一种是完全设计,一个是简单设计。 
    完全设计是指在具体编写代码之前对软件的各种方面都调查好,做好详细的需求分析、编写好全部的开发文档,设计出程序全部流程后再开始写代码。 换句话说,就是全部的计划好了,能看到最终的样子,再开战。这好像也是很多“软件工程”书里要求的那样。开始的时候,我觉得这种方法不错也。什么都计划好了,照着做就是了。不过这里有个明显的问题,就是谁来做这个完美的计划?估计只有及其BT的人了,但是大部分人的想要完全设计,并且没有错误,或者已经有几种后备的容错方案,并能准确无误的推行。以达到最终目标。这样的境界,没有很多年的工作经历是不可能的。我也没有这样的本事,所以我也就放弃了这种想法。 
    简单设计:简单设计一种概念,一种可以接受的简单的设计,最起码数据库已经定下来,基本流程已经确定的方案,来作为程序设计的开始,并随时根据实际情况的进展来修正具体的功能设计,但这种功能修改不能是修改数据库结构。也就是说数据库结构是在编程之前经过反复论证的。这种方法减少了前期设计的时间,把代码编写工作和部分设计工作放在了一起,实际缩短了项目开发的时间。如果说完全设计方法要求有很厉害的前期设计人员,那么简单设计要求有很有设计头脑的编程人员。编程人员不仅仅是K代码的人而且要负责程序架构的设计。所以对程序员的要求就很高了。 简单设计的成功的一个基点是编程人员设计的逻辑结构简单并能根据需要来调整其逻辑结构,就是代码结构灵活,简单设计带来的另外一个变化就是会议会比较多,编程人员之间的交流就变的很重要。现在一般的中小型软件公司基本上都是采用简单设计的,除非那些很大型的软件公司。 
    总结,简单设计考验的是开发人员的能力。完全设计考验的是前期设计人员和整个项目组完整能力。(各种文档的编写,开发人员一定会要写一部分的。)


    2、设计变化和需求变化 


    开发人员最怕的是什么呢?设计变化,还是需求变化?我觉得需求变化是最最致命的。当你的一个项目数据库都定下来后,而且已经开发了若干个工作日,突然接到甲方公司提出,某个功能要改变,原先的需求分析要重新改,如果这个修改是涉及的数据库的表结构更改的话,那真是最致命的。这就意味着项目的某些部分得重新推倒重来,如果这个部分跟已完成的多个部分有牵连的话,那就后果更可怕了。所以当碰到这种情况发生,作为项目经理的你就应该考虑先查责任人,究竟是自己的需求分析做的不够好,还是客户在认同了需求分析后做出的修改,如果是后者的话,你完全可以要求客户对他的这个修改负责任!那么,呵呵,客户先生,对不起了,本次新增加的需求将归入另外一个版本。如果是改变前面某个需求的定义,那么说不定就要推倒重来了,不过这个时候到不用太在意,毕竟错的是客户。(项目正式开始前没有没有说清楚其需求)。所以,各位看客,在需求分析做好后,在开工之前一定要叫客户认可签字,并且在合同上要注明,当由客户原因引起的需求改变而造成开发成本的增加,客户要为此买单地。 
    如果在需求不变的情况之下,设计发生了变化,这个仅仅是我们内部之间的矛盾,商量一下就能解决。在简单设计中,因为前期的设计是不完整的,那么当进入任何一个新的模块进行开发时,都有可能引起设计的变化。开发人员的水平的高低就基本上决定了软件的好坏。


    3、代码编写

     
    当需求定下来数据库也定下来后, 其实我们就可以进行实质性的编码了,按照我的看法,一个人单独编程最好,能随时偷懒。(上网,和MM聊聊),但是现在的软件项目越来越大,工期也越来越紧,事实上我们一个小组里面,一般有3-5程序员,所以我们要强调团队合作性。那么你写的代码使得别人要能够看懂,我们必须在实际的编写代码过程中要有详细的编码规范,编码规范在很多书籍里面都提到过。但最起码以下的一些规范是我们必须要遵守的: 
     

    一)源程序文件结构: 
    每个程序文件应由标题、内容和附加说明三部分组成。 
    (1)标题:文件最前面的注释说明,其内容主要包括:程序名,作者,版权信息,简要说明 等,必要时应有更详尽的说明(将以此部分以空行隔开单独注释)。 
    (2)内容控件注册等函数应放在内容部分的最后,类的定义按 private 、 protected 、 pubilic 、 __pubished 的顺序,并尽量保持每一部分只有一个,各部分中按数据、函数、属性、事件的顺序。 
    (3)附加说明:文件末尾的补充说明,如参考资料等,若内容不多也可放在标题部分的最后。 
     

    二)界面设计风格的一致性: 
    由于采用可视化编程,所有的界面均与Win32方式类似,相应采用的控件等也大都为Windows操作系统下的标准控件,而且参考了其他一些市面上相关的企业内部管理的应用软件。 
    基于简单易操作的原则,贴近用户考虑,用户界面采用Windows风格的标准界面,操作方式亦同Windows风格,这样在实施过程,可以降低对客户的培训,也可以使用户容易上手,简单易学。 
     

    三)编辑风格: 
    (1)缩进:缩进以 Tab 为单位,一个 Tab 为四个空格大小。全局数据、函数 原型、标题、附加说明、函数说明、标号等均顶格书写。 
    (2)空格:数据和函数在其类型,修饰(如 __fastcall 等)名称之间适当空格并据情况对 齐。关键字原则上空一格,不论是否有括号,对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。 
    (3)对齐:原则上关系密切的行应对齐,对齐包括类型、修饰、名称、参数等各部分对齐。 
    另每一行的长度不应超过屏幕太多,必要时适当换行。 
    (4)空行:程序文件结构各部分之间空两行,若不必要也可只空一行,各函数实现之间一般空两行。 
    (5)注释:对注释有以下三点要求: 
    A、必须是有意义; 
    B、必须正确的描述了程序; 
    C、必须是最新的。 
    注释必不可少,但也不应过多,以下是四种必要的注释: 
    标题、附加说明; 
    函数说明:对几乎每个函数都应有适当的说明,通常加在函数实现之前,在没有函数实现部分的情况下则加在函数原型前,其内容主要是函数的功能、目的、算法等说明,参数说明、返回 值说明等,必要时还要有一些如特别的软硬件要求等说明; 
    在代码不明晰或不可移植处应有少量说明; 
    及少量的其它注释。 
     

    四)命名规范: 
    坚持采用匈牙利变量命名惯例,所有标识符一律用英文或英文缩写,杜绝采用拼音,标识符中每个单词首字母大写,缩写词汇一般全部大写,只在必要时加“_”间隔词汇。


    4、BUG修补 


    程序出现了BUG谁来修补呢,嘿嘿嘿…… 
    最好的办法是谁编写谁修补,谁改坏谁修补。一个人改坏的代码一人去修。两个人一起改坏的代码两人一起修。


    5、开发人员的测试 


    开发人员的测试是保证代码能正常运行,在开发时候发现的错误往往比较容易修正。(另外一个好处就是没有人来骂你。因为只有你自己知道)。但是一旦软件到了测试小组那里出了问题,那么就多了很多时间来修正BUG,如果到了客户哪里才发现的BUG,那么时间就更长了,开发人员本身受到的压力也是到了最大话了。客户->公司->测试小组->开发人员。 这个完全是倒金字塔型的,承受能力差的一环很容易出事情的。 
    另外开发人员的测试除了保证代码能正常运行以外,还有一个很重要的方面就是要保证上次能正常运行的代码,这次还是能正常运行。如果做不到这点,那么BUG就不断的会出现,很多BUG也会反复出现。于是软件看上去就有修补不完的BUG了。如果出现这种情况,那么开发人员有必要再教育。一般公司教育的方式有四种。第一种,扣工资,第二种,加班,反复加班+精神攻击。 第三种,开除。第四种,调动人员来帮助那个出了麻烦的家伙。 但愿看这个文章的人不要受到前面三种教育。

    展开全文
  • 什么是软件开发

    千次阅读 2017-09-30 16:40:23
    有一个销售的同事在会议上说,你们软件开发人员真好,坐在电脑前打打代码就可以完成工作了。还有一些对软件开发不懂的老板说,你们软件开发不就是写几行代码就可以了吗。可见,没有深入软件开发的了解,永远都是这么...
  • 软件、jar版本说明

    2017-03-24 16:17:09
    软件、jar版本说明 α(Alpha) 此版本表示该软件仅仅是一个初步完成品,通常只在软件开发者内部交流,也有很少一部分发布给专业测试人员。 一般而言,该版本软件的bug(漏洞)较多,普通用户最好不要安装。 ...
  • 能够通过git克隆下载仓库代码 第一次用 git git clone https://仓库地址 git config --global user.name "就是你自己的代号" ...校验:git config -l 能够将开发的项目代码上传到仓库 git add . ...
  • 软件版本控制流程

    2020-10-15 10:33:33
    主要针对软件版本的流程, 以确保公司资产得到保护。 2.适用范围 该流程适用于产品研发部门。 3.环境资源 在整个产品生命周期中,以gitlab作为公司主要代码仓库。 4.流程 流程分为版本号定义、版本发布 4.1 ...
  • 1、瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型, 瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤...
  • 软件开发流程

    万次阅读 2012-05-03 14:57:31
    一、 软件开发简介 软件(Software)简单的说就是那些在计算机中能看的着,但摸不着的东西,概念性的说软件也称为“软设备”,广义地说软件是指系统中的程序以及开发、使用程序所需要的所有文档的集合。软件分为...
  • 第一章软件软件工程zhi的概念,这一章主要讲解的是一些概念性和基础性的内容,例如软件的概念、特性,软件危机的主要表现,软件工程的概念以及软件生存期、典型生存期模型等等。第二章软件工程方法与工具,这一章...
  • 软件项目开发基本流程详解

    万次阅读 2018-03-15 09:30:29
    软件项目开发流程图是用来详细描述了软件开发过程中产品调研、设计、开发、测试等各个阶段中各个角色,包含产品经理、研发、测试、用户等需要处理的事情,以及在不同阶段可以达到哪种效果。那么,一款软件从研发到...
  • 软件环境、硬件环境、开发工具

    万次阅读 2016-08-31 23:54:34
    软件环境:Windows操作系统 硬件环境:Android手机 开发工具:MyEclipse、AndroidStudio
  • 软件开发工程师常用工具介绍

    万次阅读 2018-05-15 02:13:28
    本文主要记录软件开发工程师在工作及学习中常用的工具,后面有时间把每个工具的基本用法都总结下。 工具合集 序号工具名称简述使用指南 1GitHub适合团队开发人员之间共同开发时使用GitHub官网 ...
  • 工控机上位机软件开发历程(一)

    万次阅读 多人点赞 2018-10-17 16:56:02
    刚到公司的时候,公司使用的是组态软件(用以显示流程图),然后再开发了报表软件、数据上传软件。因为组态软件使用的是标准Modbus协议,而很多仪器使用的协议根本就是自定义的,所以还要加一个协议转换软件,把各种...
  • 软件工程导论--软件工程概述

    万次阅读 2020-04-19 17:33:40
    1 软件软件危机 1.1 软件的特性 软件是一种逻辑实体,而非具体的物理...  软件产品一般分为两类:通用软件产品(如数据库软件、文字处理软件、绘图软件、工程管理工具…)和定制软件产品(如电子设备的控制软...
  • 对于一个刚进入公司的新人来说,在熟悉工作环境的时候,会听着几个“老人”在自己可视范围之外或者轻松的讨论着业务,其措辞拿捏精准,期间,涉及到一系列的概念,可能会让你不觉明...软件开发环境(Software Developmen
  • 软件开发是一门技术,它需要相应的理论、技术、方法、手段和工具来支持。就软件开发技术的发展而言,主要经过了结构化开发方法和面向对象的软件开发方法。  传统软件开发: 结构化开发方法:  结构化开发方法...
  • 孔子说,“工欲善其事,必先利其器”,当前运用前端开发,也是很恰当的,那么,前端开发用什么软件?前端开发用什么工具?下面php中文网就为大家总结一下前端开发开发工具。 一:HBuilder HBuilder工具是数字天堂推出...
  • 各大银行的软件开发中心

    万次阅读 2011-08-20 13:52:16
    1.1. 人行: ...软件开发中心作为人行的下属机构,人民银行的主要业务要交给软件开发中心来完成。但 并非垄断人民银行的业务。一些重大项目要在全社会招标,但软件中心同等优先。 A.开发中心成立时
1 2 3 4 5 ... 20
收藏数 1,796,595
精华内容 718,638
关键字:

软件开发