关于软件开发会遇到什么问题及对策

1. 关于软件开发会遇到什么问题及对策

调研：当确定做之后，我们就要与客户交流，进行需求分析，但由于客户表达不清、需求自身经常变动或分析人员理解有误，都会导致需求分析困难。所以，前期的调研及 开发过程中的及时沟通及汇报时很有必要的；但这是可能就会遇到一些问题，比如：前期我是想这样实现的，但我又想以另一种形式实现，这时。就会涉及到已经开 发完成的模块进行修改，造成工作量的增大，所以，要注意的是，提前考虑好或需要变动要及时与工程师沟通，看是否可以进行修改，若没问题则工程师修改，若工 程量很大，甚至涉及到整个架构了，则尽量不修改以其他形式实现。伟创软件在开发过程中经常遇到这样的问题，所以建议大家多沟通。
2
开发过程中：每个工程师都希望能再前期就能将功能梳理完毕，但是这种事情基本是不可能的，在开发过程中会出现这样那样的变动，伟创OA就经常出现这样的情况，但这并不是不可控的，只要软件还没有开发完成，与工程师协商是没有问题的，若是已经开发完了，要改动，就有可能会涉及整个底层架构，加大周期及工作量。
3
测试：测试的目的在于发现尽可能多的错误，而不是为了说明程序中没有错误。公司内部人员进行的测试，就是已知各模块的结构进行单步调试，主要是看模块接口是否正确，输出结果是否正确，请用户过来试用，发现在试用中出现的一些问题，提交测试报告。
软件开发过程中会遇到哪些问题
4
需求分析很重要，要先明确需求，然后要在设计的时候一边编程一边根据需求的改变而改变，越早修改，代价越小。
软件开发过程中会遇到哪些问题
END
注意事项
以完全定制为例列举，若是通用模板型的就没有此种问题了

2. 软件开发过程中的常见问题有哪些？

1.前言应用软件系统是事件驱动的软件系统，系统通过接口接受事件后，交由系统业务层处理，业务层处理完事件后将需要的信息存入数据库，整个应用软件系统分为三个子系统：接口子系统，业务子系统，数据库子系统，业务子系统进一步分为三个子系统：表示层，业务层，数据接入层。其中业务层是整个系统的核心，表示层负责通过接口子系统接收系统事件交给业务层处理，数据接入层供业务层使用完成数据的持久化。每个层对编程人员的技术要求是不同的，表示层需要了解的技术根据接口子系统选择的不同而不同：如windows界面，需要对MFC有比较深入的了解，web界面则要求对asp，asp.net，或jsp有比较深入的了解。数据访问层需要的技术则由数据库子系统的选择决定，另外还需要了解：ODBC，JDBC等。接口子系统的选择：windows界面，java界面，web界面，命令行接口，CTI， API等
数据库子系统的选择：关系数据库，普通文件等基于以上对应用软件系统的理解，软件开发流程的输入是用户的业务需求，输出就是系统的业务层、表示层、数据接入层的代码，以及接口和数据库,以及各种文档。因此得到比较理想化的软件开发流程图，该图使用uml中的活动图描述。2.需求分析阶段需求分析阶段的常见问题是：需求分析不够深入，对问题域没有仔细研究，急于进入设计阶段。造成这种问题一方面是因为项目管目赶进度以及存在于管理人员头脑中的根深蒂固的想法：任何时候不能让任何人员闲着，另外很大的原因是很多人不知道如何进一步深入研究问题域。需求分析阶段不仅要列出系统的use case，更重要的是要列出use case的输入输出和例外情况等，以及问题域中的对象之间的静态关系和动态关系，如对象间的包含关系，继承关系，调用关系等。需求分析阶段另外一个常见的问题是常常将需求分析等同于数据库设计，需求分析阶段定义的是系统作什么，而不是怎么做，需求分析的结果应该与具体的技术实现无关。数据库设计是技术实现的细节，应该尽可能的推迟技术细节的决策，不应该使技术细节束缚了我们对系统需求的理解。需求分析阶段应该从用户的角度对系统建模，不应将大量的技术细节暴露给用户，导致系统易用性差。需求分析阶段可以进一步细分为业务需求分析阶段和系统功能需求分析阶段。在很多研发性质的系统中，不注重业务需求分析，只有系统功能需求分析，导致开发人员知其然不知其所以然。系统功能规范文档与业务需求文档的重要区别有以下几点：内容不同：系统需求分为功能需求和非功能需求，功能需求进一步分为业务功能需求和非业务功能需求。系统需求规范文档除了包括业务需求文档中的业务功能需求，功能规范文档需要增加以下内容：系统的非业务功能需求，由于业务需求由计算机系统实现而产生的功能需求，如系统需要系统管理员管理，系统管理员的角度产生一些非业务功能需求，另外需要描述系统非功能需求：数据量，性能要求，响应速度，可用性要求，可靠性要求，界面语言要求等等。 阅读的对象不同：业务需求文档是用来与业务人员交流，功能规范文档是开发人员开发的依据 使用的语言不同：业务需求文档使用自然语言书写，而功能规范文档使用比较严谨的语言，如：uml书写 对编写人的要求不一样：业务需求编写人员只需要对业务系统熟悉，系统规范由系统架构师完成 体现系统架构师价值的地方是编写系统规范文档和业务层设计, 系统规范文档是下一步界面设计，业务层设计和数据库设计的依据，表示层，业务层，数据访问层之间是相互联系的，它们之间的关系应该在系统规范文档中找到。3.架构设计阶段架构设计阶段的常见问题是将架构设计理解为技术架构设计，实际上架构设计分为技术架构设计和业务架构设计。技术架构一般由系统软件商提供，可以在不同的应用软件系统中使用，例如：微软的MFC， SUN的J2EE等。对于一个应用软件系统，更重要的是业务架构的设计，也就是将需求分析阶段中得到的各种关系，根据系统的非功能需求将需求分析转变为代码。其实没有业务架构的设计也是可以的，很多项目中直接将对象之间的各种关系以数据库的方式实现，这样的系统不是面向对象的，因此面向对象设计的很多好处不能体现。由于在架构设计阶段中没有进一步细分，通常会导致不能准确估计任务量，造成项目计划变成摆设。4.详细设计阶段详细设计阶段一个重要的任务是系统持久化设计。对应用系统而言，持久化设计只是管理存储的机制，有多种技术手段可以选择：可以是面向对象数据库管理系统，简单的文件，或者是关系数据库，也可以是使用ORM工具等。总之应该把它留到最后作为细节处理。我们不应该将我们的系统和任何特定的技术绑定在一起。我们可以根据需求自由选择需要的持久化技术，并且保留在将来需要时更改持久化技术的自由。5.编码阶段编码阶段还处于小农经济，自给自足，没有分工合作。编码阶段以use case为粒度安排工作，这样的安排方式要求每一个开发人员必须对表示层，业务层，数据接入层的所有技术都要有比较深入的了解，由于每个开发人员各自只对自己的use case负责，对别人的use case不了解，但是每一个use case会有功能重复的地方，导致大量的重复工作。编码阶段工作安排的粒度应该是类，编码阶段工作的安排原则是先分层，再分割，按照表示层，业务层，数据访问层分开后，每一层内可以进一步分为不同类，使用测试驱动的编程方法，每个编程人员单独编写代码，并进行单元测试。每个层次的编程人员只需要对某一种技术有比较深入的了解。6.测试阶段很多人分不清什么是单元测试，什么是集成测试，什么是系统测试？测试的顺序是先单元测试，然后是集成测试，最后是系统测试。单元测试是源代码级的测试，一般由编程人员自己使用各种unit工具测试，是白盒测试。集成测试是在单元测试结束后，将一个或若干个单元作为一个子系统的黑盒测试，测试子系统内的所有组件可以正确的交互，集成测试通过对子系统不断增加新的单元最后完成整个系统的测试，集成测试不应由开发人员完成。7.结束软件开发过程中，各种辅助工具以及process很重要，但是使用工具和process的最终目的是为了更高效的在开发人员之间沟通交流，记录存在开发人员脑子里的想法，不要为了process而process。不能以为会使用MS word，就认为可以成为作家。最后引用Robert Martin的《敏捷软件开发：原则、模式与实践》中的一句话作为本文的结束：过渡信赖工具和过程以及低估智力和经验都是软件开发灾难的源泉。
注： 本文摘自网络
台州极速网络有限公司愿以雄厚的技术实力基础

3. 软件开发面临的问题都有哪些?

1. 软件开发是高风险、高投入的项目
2. 开发时间长、成本高
3. 无法证明正确性
4. 维护代价高
5. 开发、维护难于度量  等等
6. 偏激看法：凡是软件开发项目就不可能按时完成。

4. 软件开发的常见问题有哪些

不知道你想问哪些方面的问题，如果你想做软件开发，需要具备下面几个基本的素质：
1、业务能力要说的过去，最起码的要求必须完成PM/TL交给你的任务，无论你用的是C++，或者Java语言，必须要熟练运用。
2、软件行业，目前在国内，不加班是不可能的，你要做好加班，甚至通宵的准备。
个人建议，仅供参考。

5. 软件工程开发过程中应注意的问题？

本人软件工程师，你的问题可以参考下面的文章，不明的可以与我交流，谢谢采纳。
软件项目从角色分工方面可以划分为研发、开发和实施三类，每个类型的项目有各自的管理过程。下面笔者就公司实施类项目的经历，从项目经理的角度谈一谈实施类项目管理过程中应该注意的一些问题，希望大家共勉。 
　 
　　确定项目概况

　　俗话说：“万事开头难”，项目开始阶段是一个非常重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能的多从各个方面了解项目的情况。要在项目启动阶段就要了解：这个项目是什么类型的项目，具体做什么事情，是谁提出来的，目的是解决什么问题，客户方直接责任人是谁及他对待项目的态度。我们提出这些问题，并根据掌握的情况分析这些问题，目的是要找到这个项目验收的最终落槌人，并根据他的工作特点制定相应的后续工作策略。 



　　确定项目干系人 

　　要了解这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来。项目经理需要提前了解每个方面的人对这个项目的看法和期望。事先做足功课，可以让你在实施中碰到问题的时候，分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而顺利的将问题解决，让事情向你所希望的方向发展。请记住一句话：“没有永远的敌人，只有永恒的利益”。 

　　提前确保后勤保障体系 

　　“兵马未动，粮草先行”，这里的“粮草”就是资源的储备，就是参与项目的人员的业务、技术培训。根据项目特点确定项目人员规划，人员配备以期达到互补，这样对于项目实施和提高人员素质很有帮助。不是每个开发人员都适合目前的项目，最好向公司提前申请符合项目特点或者比较容易过渡的开发人员。或者是在项目需要增加人力投入的时候能够提前向公司说明，以保证有比较合适的人选。 

　　意义非凡的项目接口人 

　　和客户谈需求，协调资源，一定要客户指定统一的接口人，不能张领导、王领导都来说几句，如果他们意见不一致，那你就成“夹心饼干”了。所以，项目最初就要和客户方项目经理确定一个接口人，有什么需求你们内部先统一再和项目组谈，我不参与你们内部业务部门之间的矛盾之中，这样可以很大程度上减少客方不必要的干扰。项目接口人不一定就是客方项目经理，有时候他会指派一个人和你接口，那这个人的关系也要处好，团结一切可以团结的力量。如果遇到需求确定或者变更等需要做主的事情，那一定要请示客方项目经理，并且拿到具有证据效果（如：签字，邮件等）的反馈才行。 




　　项目情况及时反馈 

　　把项目过程中遇到的问题、进度及时向公司反应，以便能争取更多的支持。对于客户的提问或咨询也要及时反馈，但不能不懂装懂，胡乱答应，对于不太把握的事情还是要和客户委婉的解释随后给予答复，争取到时间就要及时的去确认并且以最快的速度反馈给客户，让客户觉得项目组很负责任，态度很积极。如果他提出的问题被你耽误了好多天或者干脆就忘记反馈，那客户的感觉可想而知，随后的工作就麻烦了。

6. 论文软件开发过程中遇到什么问题

01：软件项目开发合同的订立，合同需要对将来几个月甚至几年需要做的事情有个明确的定义说明，限定好工作范围、工作内容、承担的责任、项目总费用，每个阶段支付的费用都需要有明确的说明甚至付款条件等都需要一清二楚，很多东西都没讲明白是将来合作不愉快的导火索，这些都需要白纸黑字写清楚，其实从合同上也能看出甲乙双方的水平在什么层次上的。

   02：软件开发过程中，往往会发生客户不按时支付费用的事情，因为软件开发不只是脑力活儿，也是强度非常大的体力活儿，难免会遇到不能按时交付软件的可能性，除非遇上非常有经验的能相对准确评估工作量、工期的管理人员，参考历史的开发经验、再按自身团队的开发技术能力、协调工作效率，计划出一个合理的工期计划来，因为整个公司都需要考虑到资金安全、开发风险，需要有一定的水平能说服客户及时付款，至少可以支付大部分款项的人，在开发软件项目的过程中往往会发生需要垫资几十万的事情，其间需要做好防备工作需要防止资金链断裂了。

   03：软件开发人员中途离职也是家常便饭，相对规范的公司，一年也大概也会有10%的人员流动性，若薪资待遇也不怎么样、公司管理也不规范，开发人员也学不到知识、业务也不稳定的，那估计有50%的流动性也是很正常的事情，连微软、Google都会有开发人员离职现象，更何况一个不知名的公司，人员离职是很正常的现象，但是人员离职了就得需要有后备开发人员，公司管理人员需要在最短的时间内招聘到合适的人员，这也需要必备的技能。

   04：现在已经不是单枪匹马就能搞定中型软件系统的年代了，一个软件项目开发过程中往往需要N多人参与，客户对软件项目的质量要求，功能要求也越来越高，不只是需要把程序写好，还需要有各种配套文档，测试都需要跟上，所以这些人的协调工作、及时沟通也是很大的问题，若一个项目经理的沟通能力有问题也很容易遇到很多没必要的麻烦，也会使得项目进展会很不顺利的局面，甚至到有敌对力量产生的程度，一个公司，一个项目最怕的是内耗，我们国家其实很多东西也都浪费在内耗上了，若没几千年封建王朝的内耗，我们应该会发展的比美国强大很多。

7. 关于软件开发过程一些描述的问题

第二题的C，指的是编码和测试都发生在软件开发生命周期的偏后期，而前期是需求分析和各种设计的阶段，也就是说是和B对应的意思。坦白的说，现在软件开发的模型有好多种，这个题目只适用于瀑布模型，而且语言用的也略有些歧义，看上去让人觉得是开发完了以后才编码，那样肯定是错的。不过国内的考试，就这样，D是明显错的，所以就选D吧，C不能说错，只能说出题的人语言的运用不是很精准。

8. 软件开发过程中会有哪些风险？

1、未经权威部门确认的功能标准、开发规范以及质量技术标准，均可能导致软件无法达到预期标准，从而引起质量风险。
2、在理解项目标准及范围等问题上，企业管理层、项目组以及技术性人员的接不一致，导致计划与资金安排有所改变，因而极易引发风险。
3、潜在的维护、验证、接口、实现以及设计等环节出现的问题，存在技术空白及未知领域，为软件开发工作带来较大的风险。
4、来自于外包项目组、客户、国家政策以及市场等方面的变化及压力，这类风险具有明显的不可控特点，一旦遭遇，应谨慎对待，及时制定解决策略。



风险防范与控制措施
1、出台合理的软件开发模式与相关规程，确保开发工作合理、有序进行，并符合国家出台的相关标准及要求。
2、对于项目组全体成员的开发行为进行严格规范，加强小组成员之间的交流与互动，以免由于沟通与交流不当，引发软件开发风险。
3、定期开展业务和技术交流大会，引导技术人员摒除过于落后、陈旧的工作思想，通过引进先进的技术、设备与验证方式，明确技术人员的预期发展目标，令其不断的改进自我、完善自我，提升技术及设备的质量及效果。
4、对开发所用的方法及技术进行客观、合理的评价，避免由于无法把握技术而引发风险。
5、建立完善的风险应对程序与管理计划，如此一来，才能确保在发生风险的时候，能够快速、合理、技术的作出反映，并通过制定适宜的策略，对风险进行专业性处理。