软件开发需要那方面的人才呢？

你好！ 1 前言 软件开发并不是只有一个编程的人，而是可以分为不同的角色。

不同的软件公司因为规模大小性质各不相同，所以围绕软件的角色也各不相同。

一个大型的软件外包企业，外资企业，往往分工明确细致，每个人像螺丝钉一样在一起工作，让整个大机器得以运转。

而在一个小型创业企业里面，往往一个人从接触客户，到开发产品到交付产品一条龙走完，整个产品周期就一个人，甚至几个产品周期就一个人。

2 软件开发团队角色 一般的项目组可以说一共有5种角色，开发（DEV），测试（QA），质量监督（SQA），技术主管（Tech-Lead），开发经理（SDM）。

2.1 开发 （DEV） 开发就是大家经常说的编程的人。

工作主要是写代码，其次是跟团队成员客户沟通。

前后者比例大概是7:3的关系。

开发是整个软件开发团队当中的最重要的角色之一，道理很简单，产品出自于他们的亲手。

说到开发，大家的印象就是整天呆在电脑面前，目光呆滞，头发凌乱的计算机人士。

确实，整天和计算机打交道的人的确容易变成这样，因为开发首要解决的问题就是如何用技术能力去解决客户的需求，而不是自己的形象怎么样。

事实上这种情况在现代中得到很大改善，很多IT人士都很注重自身形象。

具体的工作不仅要写代码用算法实现业务逻辑，更要有程序设计的思想，大到整个的程序框架，小到某个小模块的扩展性兼容性，都是在开发真正写代码之前着重要考虑的方面。

现在的编程不像以前打孔式编程那么艰涩，大厂商开发的强大的编程工具（IDE）让编程事半功倍。

然而技术在变简单的同时，客户需求又在日趋复杂化。

而技术就是为了实现业务逻辑，将业务逻辑抽象建模用计算机程序的方式表现出来，所以一个不懂业务逻辑的开发不会了解模块和模块之间如何协同工作，这便给工作带来很大的局限性。

而如果一个开发只关注每个模块之内的细节实现，那在现实中便不是一个好开发，至少不是一个好用的开发。

沟通方面，开发需要和测试，技术主管，开发经理，甚至客户方面沟通，所以必要的沟通能力还是很需要的。

现在的软件不再是一个人在战斗，在团队作战中，开发有时需要和测试讨论“某个软件Bug（缺陷）是不是Bug”，有时需要和技术主管讨论客户的某个需求到底是要实现什么内容，有时需要和开发经理讨论项目的进度是否需要推迟。

就开发的工作本身而言，是不太需要管理能力和全局观的，如果能够做好编程的工作之外，这两方面也比较强，可能就离升职加薪不远了。

2.2 测试（QA） 任何一个产品都需要测试，就好比制造业中如果生产了一批电灯，我们不能听制灯师傅说信得过而信得过，而得通过一系列模拟用户的行为来对电灯进行测试，指标合格后方可出厂投入市场。

软件测试也一样，需要对开发者开发出来的模块，产品进行全方位的测试。

原则是“做正确的事”，让客户需求功能得到满足。

基本做事方法就是模拟客户的一切日常行为，包括一些极其变态的行为，考验软件在各个方面的情况下的可用性和稳定性。

而这些“日常行为”便称之为测试用例（Test case），一个好的QA会设计出一套可以覆盖所有检查点（check point），又不重叠的测试用例，这套功底可以参考MECE方法。

既然如此，QA就需要对整个软件的业务相当熟悉，因为她（他）要知道在某个用户行为下，软件是否做出了正确的反应。

既然是模拟用户行为，那么QA就需要去手动“跑”测试用例。

当一个系统很大的时候，测试用例极其多，光用手点一遍是非常耗费时间和人力的，所以QA可以做自动化测试。

所谓自动化，便是QA编写一些脚本代码，让计算机帮助去实现一些人为的行为，而不用自己手动点。

所以这就需要QA做有一些代码编写能力。

沟通方面，QA经常要和DEV讨论Bug（软件缺陷），Bug的意思是本应该有的功能却没有做到的功能。

对于某些比较似是而非的Bug， 怎么能够让开发者心服口服地承认并去修复往往需要花费一番口舌。

而这些Bug往往是根据不同的人的价值观认定是不是Bug，所以合理地传递价值观也是QA的一个基本素质。

现实的一个案例是，公司某QA“传递价值观”能力极强，于是被拉去做市场去了。

除此之外，QA还要经常和技术主管沟通，熟悉客户需求。

全局观是因为QA要做集成测试，这样需要对产品本身有个全局的观念。

比如产品有个用户管理系统和订单管理系统，那么对于“删除一个用户”的行为，用户的订单会怎么处理？这便是一个全局观的意识。

往往一个好的QA在这点上可以帮用户想到很多用户没想到的东西。

2.3 质量监督（SQA） 如果说QA的作用是确保“做正确的事”，那么SQA的作用就是确保“正确的做事”。

通常SQA是不会直接参与软件开发的工作中，而是通过在一旁监督软件开发的过程，然后把监测的结果反馈给软件开发团队。

既然是监督过程，所以SQA经常是流程化的代名词。

流程是外企当中比较看重的东西，从每天的Daily report， 到每周的weekly meeting，从什么时候把当天的结果存到服务器上，到为什么团队出现重大事故，几乎都会有SQA的参与。

所以在前期制定一个符合项目的流程是SQA的必然工作。

项目运行过程中...

软件开发的平台需求是什么？

万事开头难。

能否作好需求分析是一个项目成败的关键。

需求分析初始工作的好坏对后续影响极大不可不查。

我在这里提几点看法，不一定正确，算是抛砖引玉吧。

第一步：请客吃饭。

看起来很庸俗，但却是非常有效的手段，通常客户方的中高级领导工作都很繁忙，在饭局上才有时间能够摸清楚他们真正关心的和反对的，弄清楚之后，需求的方向性才不会出错。

通常来说政府机关的领导比较关心政绩，企业老板比较关心成本与销售。

第二步：摸清楚对方项目实施负责人的心态与兴趣爱好。

一般来说，客户方会指定一名懂技术的人员作为项目实施负责人，如果能够争取到他的积极配合，会在以后的工作中带来许多方便，特别是在验收的时候。

第三步：跟对方的实际操作人员（他们是软件真正的用户）交谈，观察他们的业务，记录下他们每天的工作，并要了解他们的工作是如何被考核的。

在这里不要怕花时间，你如果在这里“节约”一天时候，到头来可能会浪费一个星期也许是半个月的时间。

第四步：准备好一张纸一支笔，画系统分析图。

不要计算机，因为它会限制你想象力的发挥。

另外，当客户提出一个需求之后，都要问一个为什么他会提出这种需求，要能够分析客户需求的背景及真正原因。

否则，等软件完成之后，客户会指责缺这个少那个功能，而开发人员则会抱怨客户的需求多变，为什么当时不提出来。

软件开发需要什么条件

做软件开发的话，可以从这几个方面准备：1.准备一台电脑，装Windows XP 或者装Windows Server2.学习软件的基本理论：包括软件的设计流程、质量控制、算法。

。

。

这些都很重要，写代码只是一部分工作！！！3.最好从C开始学习，同时学习数据结构、算法等知识，建议你用清华大学的书4.学习面向对象的编程语言（OOP语言诸如C++、Java、C#），这个时候要自己选一个主攻的方向5.以上是在学习软件开发语言，现在开始对软件开发的流程有整体把握：像需求分析、算法、流程，在学的过程中都要注意，不要上来就写代码6.熟练掌握开发工具中的例子（一般在软件开发工具的文件包里有）

软件开发需要准备哪些文档？

模块开发卷宗（GB8567——88）1标题软件系统名称和标识符模块名称和标识符（如果本卷宗包含多于一个的模块，则用这组模块的功能标识代替模块名）程序编制员签名卷宗的修改文本序号修改完成日期 卷宗序号（说明本卷宗在整个卷宗中的序号）编排日期（说明整个卷宗最近的一次编排日期）2模块开发情况表3功能说明扼要说明本模块（或本组模块）的功能，主要是输入、要求的处理、输出。

可以从系统设计说明书中摘录。

同时列出在软件需求说明书中对这些功能的说明的章、条、款。

4设计说明说明本模块（或本组模块）的设计考虑，包括：a. 在系统设计说明书中有关对本模块（或本组模块）设计考虑的叙述，包括本模块在软件系统中所处的层次，它同其他模块的接口；b. 在程序设计说明书中有关对本模块（或本组模块）的设计考虑，包括本模块的算法、处理流程、牵涉到的数据文卷设计限制、驱动方式和出错信息等；c. 在编制目前已通过全部测试的源代码时实际使用的设计考虑。

5原代码清单要给出所产生的本模块（或本组模块）的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源代码清单。

6测试说明说明直接要经过本模块（或本组模块）的每一项测试，包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。

7复审的结论把实际测试的结果，同软件需求说明书、系统设计说明书、程序设计说明书中规定的要求进行比较和给出结论。

在软件开发中,需要学习哪些内容呢？

&nsp；首先让我们来看一下软件工程师考试（高级）要求： （1）理解软件工程管理的概念和任务； （2）理解软件生存期过程； （3）理解软件工程标准； （4）掌握需求分析、测试、维护基本技术； （5）掌握软件度量、软件配置管理方法； （6）理解软件复用概念； （7）理解软件质量保证的手段； （8）理解软件项目对人员的需求； （9）理解软件知识产权的基本知识。

通过本级水平考试的合格人员具有从事软件系统分析与工程系统分析员、工程管理员的实际工作能力和业务水平。

软件开发为什么需要最佳实践呢？

与许多古老的职业相比，人们从事软件开发的时间并不长。

但就在这短短的几十年中，人们根据软件行业的经验，并从其他行业（如建筑业、制造业）借鉴，总结了不少最佳实践。

特别是最近十年以来，这些最佳实践似乎分裂成为两大阵营：重型方法学和敏捷方法学。

这两大阵营的拥护者都不少，并且领军人物都是德高望重。

软件项目的目标 在讨论这些最佳实践之前，先明确一下软件项目的目标，因为所有的最佳实践都是为实现项目目标服务的。

Alistai Cockun在他的著作《敏捷软件开发》中指出，软件项目的目标有两个，取得当前项目的成功并进行积累，为后续的项目做准备。

关于第一个目标，一个比较麻烦的事情就是如何定义成功。

一般来说，大家认为在预算范围和进度计划之内交付客户想要的产品，项目就算是成功的。

但这样的理解似乎过于初级。

Dewys Lasdon曾指出，我们的工作不是用限定的费用及时地给客户他想要的东西，而是给他从未梦想过的东西当他得到的时候，他意识到这就是他一直想要的东西。

&dquo如果你结合iPod取得的成功来看，就能很好地理解这段话的含义了。

[考试大提供] 关于第二个目标，主要有两层意思。

第一层意思是锻炼队伍。

在项目中，团队共同工作一段时间，进行了许多战术配合&dquo方面的练习，大家相互之间更有默契。

对于个人来说，通过具体的开发实践，学习了不少新知识，也积累了经验。

第二层意思是为后续项目提供积累。

后续项目可能是运维项目，也可能是产品的下一个版本，或其他项目。

不少项目开发工作对于后续项目有重要意义，如项目文档和回归测试套件等。

如果你曾接手过别人的项目，或者只是花时间读过别人的程序，就一定会对此深有感触。

顺便提一下，项目的第二个目标不一定是次要目标。

对于某些领航项目或概念验证项目来说，为后续项目提供经验积累就是项目的首要目标，也是项目成功的衡量标准之一。

RUP 根据IBM的官方说法，Rational Unified Pocess是一个灵活的软件开发流程平台。

借助它可配置的构架，RUP 使你能够只选择和部署项目的每个阶段需要的流程构件。

RUP 平台以业界公认的软件工程最佳经验为核心，它包含配置 RUP 以满足项目特定需求的工具。

从这种意义上说，RUP 是一个软件开发方法框架，以及一个公认的、灵活的、实用的流程平台，用于成功的软件项目。

RUP提出了六项最佳实践： 1. 迭代的开发软件 2. 需求管理 3. 使用基于构件的体系结构 4. 可视化软件建模 5. 验证软件质量 6. 控制软件变更 让我们来看看其中的需求管理。

一项调查（James Matin An Infomation Systems Manifesto,Pentice Hall,1984）表明56%的缺陷其实是在软件需求阶段被引入的。

而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。

剩下的50%是由于需求的遗漏导致的。

更重要的是，许多需求缺陷直到很晚才被发现。

而缺陷发现得越晚，修复缺陷所需的代价就越大。

所以在传统软件工程方法中，非常重视需求工作，甚至称这部分工作为需求工程。

需求工程的主要出发点是减少需求中的缺陷，从而降低项目风险。

Joel Spolsky 指出：“首先，没有编写规格说明是软件项目中你所承担的一个最大的、不必要的风险。

”特别是在外包项目中，绝大多数客户都不会同意没有需求规格说明书的开发方式，因为这样做风险太大，实在不值得冒这个险。

需求工程的另一项重要使命是发现机会，即发现创新的产品，为用户提供更多价值的机会。

如果你草率对待需求工作，将丧失这种机会。

例如，在我们进行业务流程分析时，应该适当关注企业流程再造，业务管理创新，实现更多客户价值的机会。

只有这样，才能可能做出Dewys Lasdon所说的“客户从未梦想过的东西”。

需求工程中的一个重要方面是管理需求的可追踪性，即从项目的总体目标追踪到业务用例，再追踪到实现用例和具体需求，最后追踪到实现和测试的能力。

如果忽视了这个方面，项目的开发可能会偏离方向。

我们在写需求时，常常会用到一些文档模板，如需求规格说明书模板和用例模板。

某些模板非常全面、细致，以至于某些部分我们初看上去甚至觉得可以忽略掉。

但是当你打算忽略掉模板中的这些部分时，千万要小心，因为模板的主要作用之一就是降低遗漏需求的风险。

有一次一名项目经理打算在开发团队中引入用例模板，查找了一些资料之后，写了一个草稿让我复查一下。

我发现他的模板中没有用例的使用频度，问他时他说，觉得没有太大作用就裁掉了。

于是我告诉他，用例使用的频度对系统的设计和实现有很大的影响，这属于系统的非功能需求，不能省略。

如果你想进一步了解需求工程，推荐你读一下《掌握需求过程》这本书。

XP 在各种敏捷方法学中，极限编程（XP）是知名度最高的一种。

XP的主要实践有：Sit Togethe（坐在一起）、Whole Team（完整团队）、Infomative Wokspace（信息化工作场所）、 Enegized Wok（精力充沛地工作）、Pai Pogamming（结对编程）、Stoies（用户故事）、Weekly Cycle（每周开发循环）、Quately Cycle（每季度开发循环）、Slack（松弛计划）、Ten-Minute ...

软件开发和客户谈需求怎么样？

1、需求是开发的前提；2、开发是需求的实现；3、需求与开发本就是相应相生的关系；4、脱离需求谈开发属于无稽之谈，脱离开发谈需求是异想天开；5、与客户谈需求其实对一个人的需求更高，他不仅仅要求你具有良好的沟通协调能力，还得了解整个业务的需要，还得了解开发的过程及困难程度，能够根据客户非专业的描述，整理出能够与团队沟通的专业知识。

还要能够将专业的知识转化为客户理解的语言，并提供切实可行的详细方案，以使需求更加合理与完善。