软件开发成功案例3个

　　软件开发，是根据用户要求建造出软件系统或者系统中软件部分的一个产品开发的过程。以下是品学网小编分享给大家的关于软件开发成功案例，欢迎大家前来阅读！软件开发成功案例篇1：
　　20xx年08月
　　编委专家简介
　　陈志波
　　陈志波博士目前是Technicolor中国研究院多媒体实验室主任，视频处理编码媒体质量分析领域的专家，国际电气与电子工程师学会（IEEE）多媒体技术委员会成员，并是一些国际多媒体会议的组织委
　　员会和程序委员会成员。作为公司首先启动敏捷式研究管理的项目负责人，有四年以上的利用敏捷式（Agile）管理流程管理研究和创新团队的经验。
　　单岚
　　任职于用友医疗卫生信息系统有限公司，担任研发中心R应用开发部开发经理。20xx年7月20xx年1月，任职于中科软件集团，担任开发人员。20xx年2月20xx年4月，任职于用友软件股份有限公司客户化开发部，担任项目经理。从20xx年4月至今，担任用友医疗卫生信息系统有限公司的开发经理。目前作为R6产品的开发经理，主导并实施了项目实施支持网系统，在研产品并不成熟的情况下交付了多个项目，有效的打通了一线实施与研发部门的沟通渠道，并对在研产品的功能和易用性上做了非常大的提高和完善。
　　高航
　　任职于用友医疗卫生信息系统有限公司，担任G应用开发部开发经理。从事软件开发5年，精通JAVA系列技术，熟悉Delphi技术。在社保和医疗行业有着丰富的业务建模和系统架构经验。目前专注于软件研发团队的管理、软件研发流程的工具化实践与优化，并积极探索敏捷化开发在工程实践中的应用。
　　顾焱
　　任职于用友软件股份有限公司，担任NC产品本部副总经理。20xx年加入用友软件，历任NC资金开发部经理，NC供应链开发部经理，NC产品本部副总经理。致力于大型管理软件开发10余年，在实践中不断尝试改进开发过程，为建立高效适应快速变化市场的开发团队不懈努力。
　　何宇
　　任职于汤森路透，担任GEDA部门的TechnicalTeamManager。7年软件行业开发经验，曾服务于欧美日等大型外资企业，从事过外包项目、大型ERP系统开发、成熟系统维护改造、以及新系统设计开发等多种类型开发管理工作。熟悉CMMI、SCRUM等软件开发流程。在多个项目中推广使用SCRUM，交付了数十个迭代，积累了宝贵的经验。
　　黄方
　　任职于ElectronicArts上海公司，担任ScrumMasterProjectManager。CSP，CSD，CSPO，CSM，PMP，十二年IT工作经验，七年传统项目管理经验，三年敏捷项目管理经验，带领多个Scrum团队从事游戏开发工作。
　　李春林
　　任职于东软集团，担任过程改善中心副主任。中国敏捷软件开发联盟副秘书长，资深过程改善顾问，MBA，CSM，ASPICEProvisionalAssessor。1999年加入中国最大的软件解决方案及服务提供商东软集团，拥有20xx年软件开发和过程改善经验。先后从事嵌入式软件系统研发、测试和项目管理工作，后专职从事过程改善工作，参与了东软集团质量体系文件的编写，曾作为评估组主要成员在20xx年和20xx年两次实施了CMMIv1。15级评估，并作为管理者领导了东软集团20xx年和20xx年的CMMIv1。25级评估。
　　刘德意
　　任职于特艺（中国）科技有限公司（TechnicolorChina），担任北京研究院质量与项目管理部经理。十年以上软件开发及项目管理经验，自20xx年逐渐转入质量管理、过程改进。先后帮助所在公司通过CMM2、CMMI3的正式评估，以及公司内部评估。20xx年开始，从在Technicolor中国的北京研究院推行Scrum，并逐渐走入正轨。通过多年实践，深信过程改进要以人为本，讲求实效。本人是Agile的积极参与者，曾在20xx年的AgileTourBeijing活动中演讲。
　　刘曙光
　　任职于广州畅盟信息科技有限公司，担任IT部门技术总监，有10多年IT行业的工作经验，对软件工程及其技术服务有着深厚的理解和认识，曾为电信、电力等行业多个客户提供软件工程咨询及技术支持服务。目前主要专注于ALM和自动化测试方向。
　　卢旭东
　　任职于广联达软件股份有限公司，担任总裁办研发副总裁。有销售、市场、项目管理、产品管理、技术管理等丰富的经验，曾担任过广联达PMO的经理，对敏捷及敏捷咨询和实施有非常独特的理解，是他带领PMO在公司实施敏捷并取得显著成效，他是公司敏捷实施成效的有力保障。
　　马娜
　　任职于沈阳东软集团（大连）有限公司，担任基础软件事业部产品管理中心专员。近20xx年的IT从业经验，从事过测试、配置管理、项目管理等工作，对于RUP和Scrum软件研发管理方法有3年左右的实践经验，取得PMP认证。
　　宁德军
　　任职于IBM，担任IBMRational大中国区技术总监、中国石油大学兼职教授、中国敏捷联盟副主席。有超过20xx年的产品及项目管理和软件工程经验，先后在上海贝尔阿尔卡特比利时研发中心、IBM工作，拥有丰富的跨国项目和跨国公司产品管理经验。曾为华为、中兴、爱立信、腾讯、上海电力、工商银行、交通银行、中国银行等数十家企业提供咨询和培训服务。目前专注于产品及项目组合管理、敏捷开发过程和企业架构等新技术的研究。
　　潘炜
　　任职于汤森路透，担任STrading部门SeniorSoftwareEngineer。毕业于北京邮电大学，工学硕士，3年多专业行业软件研发经历，先后就职于斯伦贝谢、汤森路透等500强外资企业研发中心。擅长微软平台相关研发技术，熟悉敏捷开发流程，目前担任汤森路透固定收益类新产品研发团队SCRUMMaster。
　　庞建荣
　　特艺（中国）科技有限公司机顶盒事业部RDOfficeLeader，20xx年软件开发及项目管理经验，8年质量管理及过程改进经验，曾在大型石油化工行业、移动通讯行业及消费电子产业供职，先后从事软件开发、项目管理、质量保证、过程改进等工作，参与企业的CMM评估、ISO9000内审外审，认证的ISO内审员，、CMM内部评估员、CSM。
　　彭渺
　　任职于广联达软件股份有限公司，担任PMO项目管理专员。有7年开发经历，PMO从事四年项目管理咨询和实施工作，在经历过多种项目和产品的敏捷咨询和实施，对敏捷有深刻的理解。
　　宋洋
　　任职于东软集团，担任AVNCIS事业部过程改善顾问。拥有9年的软件开发和过程改善经验，从事过软件开发、软件测试和项目管理工作。以质量体系审核员和CMMI1。2评估组成员的角色参与ISO9000外部评估和CMMI5级外部评估工作。目前主要从事过程管理方法和质量管理工具的引入和开发工作，通过引入敏捷的方法和实践，提升项目的过程效率和产品质量。
　　孙红伟
　　任职于畅捷通软件有限公司，担任开发资源一部项目经理。参与新一代业务通11。0的设计工作，主要进行销售模块及部分基础档案的设计工作，期间参与平台组件验证，在11。0产品研发的中后期开始进行常州研发基地的开发管理工作推动业务通11。0Beta版本发布。在用友通11。2的产品研发过程中担任生产制造领域的部门经理，推动生产制造产品的研发过程，直到用友通11。2产品的发布。
　　王鑫
　　任职于新聚思（Synnex）信息技术有限公司，担任ITEPG总监。分管synnex公司过程改进、产品质量8年以上；拥有20xx年的软件研发、项目管理与质量管理经验；精通CMMI、敏捷等方法论。作为EPG负责人，目前专注于利用CMMI、敏捷等方法提升组织效率、质量及相关IT管理工具的开发。软件开发成功案例篇2：
　　为了方便学校院系考评本院系各班级预备党员的学风、品行，作为预备党员转正的参考依据，校方委托我团队设计制作校园预备党员评优系统，通过学生不记名在线打分的形式考评预备党员的各项素质，并按照各项考评分数给出每个被评分人员的综合考评得分以及排名情况。建设目标：学生考评做到有理有据，公平公正为了方便学院领导对每个处于预备转正期的学生的综合考评，学院除了要考评其个人学习成绩外，还要听取广大师生的意见，从而为我党选拔品学兼优的人才。
　　为此考评系统从学生的德、智、体、美、劳以及宗教信仰共6个方面进行考评，并为每个考评设定优、良、差三个等级供师生评判，且采用网上在线投票的形式进行打分，同时禁止重复打分，恶意修改分数，跨班级打分等现象，进而做到有理有据，公平公正。解决方案：校园预备党员评优系统评优系统分为三大模块，用户管理模块、学生评分模块以及考核统计模块。用户管理模块，收录参与评分师生以及预备党员的个人信息，系统会给出预备党员的个人信息描述，以便评分者了解，而评分师生则只收录登录用户的基本资料，方便管理。学生评分模块，评分师生对预备党员的6项指标进行评分，等级为优、良、差三个级别，系统后台则会记录不同等级对应的分值。系统会记录每个评分师生的评分操作，以防止跨班级评分，修改评分，重复评分等现象。考核统计模块，学院党支部老师可以从班级、专业、个人、考评项目等多维角度查看被评者的分值，进而从多方面了解该生的情况。
　　项目收益：使校方能从多个角度了解，认识学生校园预备党员评优系统不仅仅是一个针对预备党员个人素养的综合考评工具，更重要的是，它能够帮助校方更好的了解自己的学生，包括学业、爱好、性格、宗教信仰、为人处事等，为学校选拔优秀人才，预防校园不良事件提供了一定的支持。
　　智能表单系统在网站中经常会遇到需要用户填写一些资料的情况，这个过程对于用户来说没有任何问题，但如果表单样式经常修改，对于网站开发人员来说，将是一个比较繁琐的过程，他除了要修改表单的网页样式，还要相应的修改后台数据库的样式。是否有一种软件，既能实现表单创建、数据库表创建以及表单发布一站式服务，又能让非计算机技术人员轻松掌握，智能表单系统应运而生。建设目标：表单创建及发布一站式服务，非计算机专业用户轻松掌握智能表单系统面向的主要用户是那些不懂计算机编程，并且需要经常发布表单或者修改表单的网站文案人员，借助这套系统，用户只需简单的拖拽一些表单控件，并为这些控件命名，告知信息录入人员该填写的条目项即可，而数据库表则在发布后自动生成，无需技术人员另行建立。解决方案：智能表单系统智能表单系统的核心价值就是简单易用，且高度自动化。
　　它完全基于BS架构开发，能够很好的应用与网页表单。智能表单系统由表单引擎、数据库引擎、信息发布及处理引擎组成。1、表单引擎，负责表单控件以及表单界面的生成；2、数据库引擎，负责表单对应数据库表的生成；3、信息发布引擎，负责表单生成后的网站发布；4、信息处理引擎，直接面向信息录入人员，接收信息的录入以及数据库信息的调取；智能表单系统不仅仅允许新增表单及其数据库表，同时也允许用户在线修改字段，包括添加、修改名称以及删除字段，相应的数据库表也会改变，做到了全程自动化。产品特色及用户受益：一站式服务，简单易用智能表单系统具有表单创建、修改、发布、数据库表的编辑一站式特性，用户只需简单的拖拽控件即可完成这一整套工序。这套系统能够缩短网站表单建设周期，同时也解放了开发人员。软件开发成功案例篇3：
　　一、项目实施进度评估。ERP项目是复杂项目，其涉及的部门、人员、资金、资源等对于任何一个企业来说都是空前的，而在上一节中我们通过项目三角形分析出来，项目的进度是否能够按照设计规划的进行是影响项目效果的关键因素，所以评估项目的成功与否，首先必须评估项目的进度是否按照预期的进度进行，如果每一步或者每一阶段，都能够严格的按照进度进行，相信项目会成功的，否则就是项目设计出现了问题。一般来说现在评估项目实施进度的方法可以使用目前最为常用的项目管理工具，其中Microsoft的Project就是不错的工具之一。其实很多项目的实施失败原因是虎头蛇尾，开始的时候大家心气十足，进度基本可以按照计划进行，而到了后来，每个人的工作都是交叉的，往往会受到其他工作的影响而忽视了项目的进度，致使项目进行不下去。所以除了有相应的制度保障之外，一定要有工具，再者说了搞IT的人不用IT工具，那不是卖盐的喝淡汤吗？当然现在的IT行业非常普遍。
　　二、项目成本评估。项目成本是评价一个项目是否成功的第二个关键因素，同样在项目三角形中成本占了一条边，所以成本的变化将直接影响项目的成功，如果一味追求项目的功能和进度，而忽视成本，那将不是搞项目，而是在赌博。现在的ERP项目本身的费用就很高，而且没有公开价格，国家价格监督都没有依据，全靠软件商的一张嘴，说多少是多少，会侃价的省点，不会侃价的就多花点。但是一旦我们已经和软件公司和服务公司（咨询公司）达成了一致意见，关键的问题就在于如何有效的利用双方同意的费用达成预期的任务目标，而往往在项目的开始企业的管理者认为项目刚刚开始，投入还不多，而不注重有效控制成本，而到项目实施一段时间之后，发现项目的预算已经不能保证项目的完成了，或者半途而废，或者追加投入，而追加投入又会遇到企业资金是否充足的影响。所以我们建议在项目开始之前一定尽量准确的做出项目预算，并拿出专款，避免在途中因资金影响项目进展。另外成本控制要从采购、人员工时等多方面严加控制。并建议分阶段进行成本评估，如果每个阶段都能够在成本控制范围之内最终的项目一定保证在成本范围内成功，关键在于当出现项目费用超出预算成本的时候要及时调整，确保总体成本控制在范围之内。
　　三、项目功能评估。ERP是功能性产品，最终项目是否成功很重要的一点要看功能，看功能是否达到了预期的要求。ERP的功能从总体上来说分为几大部分：进销存管理，或者现在有的公司定义的内部物流管理；财务管理，包括总账、应收账、应付账、固定资产等；计划管理，在企业中大都会涉及到两种生产模式的计划方法，分别是单件小批量生产模式的MRP计划方法和大规模流水线生产模式的JIT计划方法；粗能力计划和细能力计划等核心资源管理；另外还包括人力资源管理；设备管理；工、模、量、夹具管理；质量管理等外围资源管理。一般来说，软件商在签约之前都会给企业的管理者演示他们的功能，我告诉企业一个秘诀，在观看演示的时候一定要刨根问底的看功能，而不能走马观花的浏览。两者之间的区别就在于不要被软件商的演示者的各种托辞搪塞过去，一定要亲眼看到他们说能够实现的功能，不要相信没有数据不能演示、不是最新版本等解释理由。如果他们说有什么功能就当场拿出来。否则就是没有，在事实面前任何理由都是苍白的。在项目结束之前，对照双方约定的功能清单，逐个推敲，如果每一个功能都实现了，项目一定能够成功。
　　四、项目效果评估。功能具备只是基本的要求，关键还要看效果，这一点可能有人不容易理解，其实在ERP管理软件中有很多功能从表面上看功能和效果是有很大的区别的，比如MRP计划，可能大多数的ERP软件现在都能实现这个功能，但是是否准确，是否可以通过MRP计划直接指导生产，甚至直接根据计划产生的结果安排采购，这并不是任何一家软件都可以做到的，这里面涉及到计算方法是否科学，是否符合行业的规范，考虑的因素是否完整，预置的参数是否科学，比如提前期设计的是否合理，安全库存设计的是否合理等等都会直接影响计划的结果，其实真正的软件公司的功底就在这里区别。
　　五、可操作性评估。ERP软件的最终目的是让企业的广大职工都能够使用，所以可操作性如何是项目成功与否的另一项重要指标。企业的大多数使用者，尤其是一线的职工，计算机的水平都不会太高，如何让软件具有很容易操作的界面，让普通的职工也能够使用软件来操作，确保每一位使用者都能够方便快捷的使用ERP软件是项目成功的重要条件。有很多软件功能很强，但是就是操作起来难度也很大，非专业人士无法使用，这绝对不是优秀的ERP软件，优秀的软件应该是只要熟悉业务的人就可以操作，所谓所见即所得。
　　六、项目的延续性评估。ERP项目是企业赖以发展的长期投资项目，绝对不是消费型项目，所以项目是否能够伴随着企业的发展而持续得到应用是评估项目成败的另一向重要指标。持续性体现为升级能力、功能的扩展能力、客户化能力、跨平台能力等几方面：现在的软件平台每几个月就升级一次，当然应用系统的升级不一定要求紧跟系统软件的速度，但是也要及时升级，随着管理理论和管理方法的不断发展，管理软件的升级至少要跟得上管理方法和计算方法的更新速度，否则就是落后的；功能的扩展能力，就像上面我们所说的功能是评估的一项指标，但是功能能否根据企业的发展而及时更新，另外还有客户化的能力和跨平台的能力也很重要。软件开发中的注意事项：
　　1、项目设计
　　项目设计的主导思想，我觉得可以理解为两种，一种是完全设计，一个是简单设计。
　　完全设计是指在具体编写代码之前对软件的各种方面都调查好，做好详细的需求分析、编写好全部的开发文档，设计出程序全部流程后再开始写代码。换句话说，就是全部的计划好了，能看到最终的样子，再开战。这好像也是很多软件工程书里要求的那样。开始的时候，我觉得这种方法不错也。什么都计划好了，照着做就是了。不过这里有个明显的问题，就是谁来做这个完美的计划？估计只有及其BT的人了，但是大部分人的想要完全设计，并且没有错误，或者已经有几种后备的容错方案，并能准确无误的推行。以达到最终目标。这样的境界，没有很多年的工作经历是不可能的。我也没有这样的本事，所以我也就放弃了这种想法。
　　简单设计：简单设计一种概念，一种可以接受的简单的设计，最起码数据库已经定下来，基本流程已经确定的方案，来作为程序设计的开始，并随时根据实际情况的进展来修正具体的功能设计，但这种功能修改不能是修改数据库结构。也就是说数据库结构是在编程之前经过反复论证的。这种方法减少了前期设计的时间，把代码编写工作和部分设计工作放在了一起，实际缩短了项目开发的时间。如果说完全设计方法要求有很厉害的前期设计人员，那么简单设计要求有很有设计头脑的编程人员。编程人员不仅仅是K代码的人而且要负责程序架构的设计。所以对程序员的要求就很高了。简单设计的成功的一个基点是编程人员设计的逻辑结构简单并能根据需要来调整其逻辑结构，就是代码结构灵活，简单设计带来的另外一个变化就是会议会比较多，编程人员之间的交流就变的很重要。现在一般的中小型软件公司基本上都是采用简单设计的，除非那些很大型的软件公司。
　　总结，简单设计考验的是开发人员的能力。完全设计考验的是前期设计人员和整个项目组完整能力。（各种文档的编写，开发人员一定会要写一部分的。）
　　2、设计变化和需求变化
　　开发人员最怕的是什么呢？设计变化，还是需求变化？我觉得需求变化是最最致命的。当你的一个项目数据库都定下来后，而且已经开发了若干个工作日，突然接到甲方公司提出，某个功能要改变，原先的需求分析要重新改，如果这个修改是涉及的数据库的表结构更改的话，那真是最致命的。这就意味着项目的某些部分得重新推倒重来，如果这个部分跟已完成的多个部分有牵连的话，那就后果更可怕了。所以当碰到这种情况发生，作为项目经理的你就应该考虑先查责任人，究竟是自己的需求分析做的不够好，还是客户在认同了需求分析后做出的修改，如果是后者的话，你完全可以要求客户对他的这个修改负责任！那么，呵呵，客户先生，对不起了，本次新增加的需求将归入另外一个版本。如果是改变前面某个需求的定义，那么说不定就要推倒重来了，不过这个时候到不用太在意，毕竟错的是客户。（项目正式开始前没有没有说清楚其需求）。所以，各位看客，在需求分析做好后，在开工之前一定要叫客户认可签字，并且在合同上要注明，当由客户原因引起的需求改变而造成开发成本的增加，客户要为此买单地。
　　如果在需求不变的情况之下，设计发生了变化，这个仅仅是我们内部之间的矛盾，商量一下就能解决。在简单设计中，因为前期的设计是不完整的，那么当进入任何一个新的模块进行开发时，都有可能引起设计的变化。开发人员的水平的高低就基本上决定了软件的好坏。
　　3、代码编写
　　当需求定下来数据库也定下来后，其实我们就可以进行实质性的编码了，按照我的看法，一个人单独编程最好，能随时偷懒。（上网，和MM聊聊），但是现在的软件项目越来越大，工期也越来越紧，事实上我们一个小组里面，一般有35程序员，所以我们要强调团队合作性。那么你写的代码使得别人要能够看懂，我们必须在实际的编写代码过程中要有详细的编码规范，编码规范在很多书籍里面都提到过。但最起码以下的一些规范是我们必须要遵守的：
　　一）源程序文件结构：
　　每个程序文件应由标题、内容和附加说明三部分组成。
　　（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了。如果出现这种情况，那么开发人员有必要再教育。一般公司教育的方式有四种。第一种，扣工资，第二种，加班，反复加班精神攻击。第三种，开除。第四种，调动人员来帮助那个出了麻烦的家伙。但愿看这个文章的人不要受到前面三种教育。