开发一般流程ppt课件

1、WEB工程开发的普通流程总纲需求分析确实定(最重要)架构与设计架构分析与设计业务逻辑分析业务逻辑设计界面设计开发环境搭建开发-测试-开发-测试培训文档编写开发的普通流程需求分析为什么需求分析 需求分析是指了解用户需求，就软件功能与客户达成一致，估计软件风险和评价工程代价，最终构成开发方案的一个复杂过程，在这个过程中，用户确实是处在主导位置，需求分析工程师和工程经理要担任整理用户需求，为之后的软件设计打下根底。需求分析阶段终了后，要求得到相关的需求文档， 需求分析之所以重要,就由于他具有决策性,方向性,战略性的作用,他在软件开发的过程中具有举足轻重的位置.大家一定要对需求分析具有足够的注重.在一

2、个大型软件系统的开发中,他的作用要远远大于程序设计. 需求分析的义务 需求分析的义务就是处理“用户要做什么的问题,就是要全面地了解用户的各项要求,并准确地表达所接受的用户需求 ，并且可以根据本人对用户需求的了解，劝说并诱导客户剔除不合理的需求。需求分析过程需求分析过程需求开发过程域 需求开发过程域 需求开发的目的是经过调查与分析，获取用户需求并定义产品需求。 需求调查的目的是经过各种途径获取用户的需求信息原始资料，产生。 需求分析的目的是对各种需求信息进展分析，消除错误，描写细节等。常见的需求分析方法有“问答分析法和“建模分析法两类。 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准

3、确无误的产品需求，产生。系统设计人员将根据开展系统设计任务。 需求管理过程域需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同了解，维护需求与其它任务成果的一致性，并控制需求的变卦。 需求确认是指开发方和客户共同对需求文档进展评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪是指经过比较需求文档与后续任务成果之间的对应关系，建立与维护“需求跟踪矩阵，确保产品根据需求文档进展开发。 需求变卦控制是指根据“变卦恳求审批更改重新确认的流程处置需求的变卦，防止需求变卦失去控制而导致工程发生混乱需求开发过程中困难知识技艺问题 行业知识是无边无际的。俗话说“隔行

4、如隔山，需求分析员能够是某一领域的专家，但当他接手陌生的业务时，他该怎样办？首先他要有勇气做事，否那么连实际的时机都没有。其次他该当赶紧补习这一领域知识，不论是经过自学还是培训的方式，否那么他很难与用户交流。假设能够的话，开发方最好请既懂软件又懂运用域知识的行家来协助。需求开发过程中困难态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到费事、波折时，他们会发牢骚，找出一堆用户的缺陷。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该通知我们该当开发什么吗？假设用户说不清楚需求，或者经常变卦需求，这类问题是用户产生的，该当由他们本人担任。 用户

5、说不清楚需求或者需求发生变卦，这些都是常见的问题，并不是绝症，是人们可以设法处理的。可悲的是开发人员把这些问题当成了借口，不愿自动攻克问题，导致需求问题分散到整个软件开发过程，产生太多的后患。 软件企业的指点该当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，假设做不到就是失职，不要找借口。 协作关系 假设需求分析员不能与用户建立良好的协作关系，那么他们在需求开发过程中会很疲惫。 倘假设用户不能很好地配合需求分析员，那并不表示他是个坏蛋。由于用户有他本人的想法：我回答了他们的问题，讲了该讲的。我们付钱给他们，难道还要我伺候他们不成？我还要干本人的事情

6、，别打扰我了。他们本人想方法把活干好吧。 需求分析员不是销售人员，他们不能够象销售人员那样经过某些手段笼络住用户就能胜利。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通才干。开发方与用户的协作关系对需求开发而言是至关重要的。对于艰苦的、复杂的工程，我们不能完全期望双方可以自发地建立起良好地协作关系，这样风险太大。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权益与义务，即以协议的方式确定协作关系。“好话和“丑话都说在前头，这样能减少今后的摩擦。假设条件允许的话，开发方最好为用户举行关于需求工程的培训，这样的培训将运用户明白需求的重要性以及忽视需求的危害

7、性，从而促使他们积极友善地参与需求工程中的各项活动。 用户在需求工程中的“权益用户在需求工程中的“权益 1. 有权要求开发方派遣资质合格的需求分析员和相关人员。2. 有权要求开发方采用用户熟习的言语来描画需求，即开发方必需提供用户看得懂得需求文档。3. 有权审查需求文档，并对有争议的需求作出决策。假设以为需求文档不能准确地反映用户真实的志愿，可以回绝在需求文档上签字。 4. 假设用户想要变卦需求，有权要求开发方对该变卦将产生的影响作出真实可信的评价，以便用户决议能否变卦需求。用户在需求工程中的“义务用户在需求工程中的“义务 1. 以积极友善的态度与开发方人员交流、协作，尽能够地为开发方人员提供

8、任务和生活上的便利。 2. 乐意接受需求分析员的采访，在不走漏的前提下尽能够地回答需求分析员的问题。3. 在不走漏的前提下，尽能够地向需求分析员提供与需求相关的资料。 4. 与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的志愿。5. 对专业性太深化的知识领域，用户有义务组织开发人员进展简单的培训。 需求没有做好的后果 如何预备调查需求需求分析员该当确定需求调查的方式，例如： 与用户担任人交谈，向用户提问题。同未来此软件的目的用户交谈，了解他们的目前的任务情况.观赏用户的任务流程，察看用户的操作。 与同行、专家交谈，听取他们的意见。 分析曾经存在的同类软件产品，提取需求。 从行业规

9、范、规那么中提取需求。如何做好需求分析为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。 谁都知道这不是真的。现实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。需求分析是指在需求开发过程中，对所获取的需求信息进展分析，及时排除错误和弥补缺乏，确保需求文档正确地反映用户的真实意图。 需求分析是需求开发过程中最费脑子的任务。分析方法大体有两类：“问答分析法和“建模分析法。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用保他一学就会，很有适用价值。 “问答分析法比较适宜于用户需求调查阶段“建模分

10、析法比较适宜于产品需求定义阶段。问答分析方法问答分析方法 问答分析方法很简单：刨根究底地问，假设问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答地分析需求，几个人分析需求那么称为“研讨。 问答分析最重要的问题是：“是什么,做什么和“为什么。每个需求都该当用陈说句阐明“是什么，假设“是什么的内涵不够明晰，那么应补充阐明“不是什么。假设“是什么和“不是什么并不是“理所当然的，那么该当解释“为什么，以便加深读者的了解。清查“是什么和“为什么的目的是获得正确、清楚的需求。 其它常见的问题有： 需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？ 需求是必要的吗？ 需求可实现吗？ 需

11、求可验证吗？ 需求的优先级确定了吗？ 建模分析法人们都有这样地感受：有些时候用言语描画某个问题特别费力，而采用图形那么使人一目了然. 在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描画需求是很自然的方法。需求建模就是指用图形符号来表示、描写需求。建模分析方法主要有两大类：“构造化分析法和“面向对象分析法。 恰当地运用图形符号：现代建模工具如Rose、Jude有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要留意的是：在建模时运用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包

12、罗万象的图它能完好地描画需求。需求建模不能够取代文字描画。在需求文档中，文字描画是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文援用。 分析决策当需求从四面八方搜集来后，需求的冲突在所难免。对于那些难以达成共识的需求而言，经常会发生“公说公有理，婆说婆有理的景象。那么需求分析员终究应该听谁的呢？ 假设一群人对需求有争议，并不是谁声音最响就听谁的。根据生活阅历，最保险的方法是：先听官儿大的或者声威高的，假设大家的职位和声威都差不多，那么采用“少数服从大多数的原那么。假设一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策该当以

13、商业利益为导向， 即哪一类客户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。 当开发者想象中的产品与客户所提的需求有冲突时，普通该当尊重客户的观念。但是不要堕入“客户总是对的圈套里，需求分析员该当纠正明显不合理的客户需求。假设产品很复杂，双方都不太明白需求，此时最好请开发人员快速构造软件的原型，双方看着软件原型再分析需求什么是好的需求规格阐明书正确 需求规格阐明书该当正确地反映用户的真实意图，“正确是最重要的属性。假设“不正确仅仅是由于错别字呵斥的，那么多检查几遍文档就能处理问题。真正的困难是开发者和用户本人都不明白用户终究“想要什么和“不要什么。为确保需求是正确的，开发方和用户

14、必需对进展确认。 清楚 清楚的需求让人易读易懂。清楚的反义词是“难读、“难了解。他可以采用反问的方式来判别需求文档能否清楚：文档的构造、段落能否乱七八糟？上下文能否不衔接？ 文档的语句能否模糊其词、罗里罗嗦？ 看了半天能否还不明白需求终究是什么？ 无二义性 “无二义性 是指每个需求只需独一的含义。假设一个人说的话，不同的人能够有不同的了解，那么这句话就有二义性。假设需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性，人们在写时措词该当准确，切勿模棱两可。 什么是好的需求规格阐明书一致 “一致Consistent是指中各个需求之间不会发生矛盾。矛盾经常埋伏在需求文档的

15、上下文中。 必要 中的各项需求对用户而言该当都是必要的。可以把“必要比喻为“雪中送炭。“必要往前一步，要么是“画蛇添足要么是“锦上添花。“画蛇添足显然是坏事，会导致开发人员多干一些费劲不讨好的任务。所以要尽量剔除需求规格阐明书中“画蛇添足的那些需求。“锦上添花是好事，能够会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者该当集中精神先完成必要的需求，假设条件允许那么再做“锦上添花的需求。为了防止主次颠倒，该当在中将那些“锦上添花的需求设置为较低的优先级。什么是好的需求规格阐明书完备 “完备Complete是指中没有脱漏一些必要的需求。人们往往倾向于关注系统的特征功能，而忽视了其它

16、一些不起眼的但却是必需的功能。 不完备的将导致产生功能不完好的软件，用户在运用该软件时能够无法完成预期的义务。 什么是好的需求规格阐明书可实现 中的各项需求对开发方而言该当都是可实现的Attainable。“可实现意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子，他们往往对用户提出的需求“来者不拒。吹牛皮虽然不犯法，但是可是白纸黑字啊。经过双方确认的相当于商业合同，假设开发方不可以实现中的内容，那就是违约，能够会被罚款的。 对于合同工程，假设开发方不能确信某些需求能否可实现，那么应事先与用户协商，达成一致的处置意见，防止未来发生商业纠纷。 什么是

17、好的需求规格阐明书可验证 中的各项需求对用户方而言该当都是可验证的Verifiable。假设需求是不可验证的，那么用户就无法验收软件，能够会发生商业纠纷。 例如，摩天大楼的一项需求是“抗十二级台风，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来实验？假设双方都认可“采用计算机模拟十二级台风等效于实践测试，那么这项需求就是“可验证的什么是好的需求规格阐明书确定优先级 为什么要确定需求的“优先级？ 实际上讲，软件的一切需求都该当被实现。但是在现实之中，工程存在“进度、费用、人力资源等限制。在工程刚开场的时候，开发方和客户比较乐观，什么都要做，

18、可是做着做着，人们经常会面临“进度延误、费用超支、人员缺乏等问题，这时就乱套了。人们想出了“取舍方法：先做优先级高的需求，后做甚至放弃优先级低的需求，这样可以将风险降到最低。 需求的优先级其实就是需求“轻重缓急的分级表述，例如划分为“高、中、低三级。普通地，由用户和开发方共同确定需求的优先级。 什么是好的需求规格阐明书论述“做什么而不是“怎样做 的重点是论述“做什么，而不是论述“怎样做。“怎样做是系统设计和实现阶段的事情。 国内的很多软件公司里，开发人员经常身兼数职，能够把需求开发、系统设计、编程等任务从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎样做，这并没有什么过错。假设在调

19、查、定义需求时想好了“怎样做，当然应该写下来，否那么岂不浪费！关键是不要将“怎样做写到需求规格阐明书里面，记录在其它文档里就行了。如何定义产品需求第一步：细化并分析用户需求 需求分析员首先对进展细化，对比较复杂的用户需求进展建模分析，以协助软件开发人员更好地了解需求。例如采用Rational 的Rose工具进展需求的建模分析，建模分析产生的文档可以作为的附件。补充阐明：建模分析的技术难度比较高，需求分析员该当根据本身程度进展取舍。 第二步：撰写产品需求规格阐明书 需求分析员按照指定的文档模板撰写。假设待开发的产品分为软件和硬件两部分的话，那么该当撰写和。第三步：进展需求确认工程经理约请同行专家

20、和用户包括客户和最终用户一同评审，尽最大努力使可以正确无误地反映用户的真实志愿。 需求评审之后，开发方和客户方的责任人对作书面承诺。 需求文档与的主要区别与联络前者主要采用自然言语和运用域术语来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机言语和图形符号来描写需求，产品需求是软件系统设计的直接根据。 两者之间能够并不存在一一影射关系，由于软件开发商会根据产品开展战略、企业当前情况适当地调整产品需求，例如用户需求能够被分配到软件的数个版本中。软件开发人员该当根据来开发当前产品。 需求确认评审和承诺需求确认评审和承诺 需求确认是指开发方和客户方共同对进展评

21、审，双方对需求达成共识后作出承诺。需求确认包含两个重要任务：“需求评审和“需求承诺。人们在交流的时候，经常会发生“问非所求，答非所问的事情，用户表达的需求，不同的开发人员能够有不同的了解。假设需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能防止： 有个外星人间谍埋伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。有趣的是，车里住着一种叫作人的寄生虫，这些寄生虫完全控制了车。 不论是复杂的工程还是简单的工程，需求分析员和用户都有能够误解需求。所

22、以需求确认任务属于需求管理必不可少需求评审面临的困难需求评审的一个通病是“虎头蛇尾。需求评审确实乏味，也比较费脑子。刚开场评审时，大家都比较仔细，越到后头越马虎。 需求评审涉及的人员能够比较多，有些时候让这么多人聚在一同破费比较长的时间开会并不容易例如有些人能够出差在外，有些人能够事务缠身。没有必要把一切事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进展。这样每次评审的时间比较短，参与评审的人员也少一些，组织会议就比较容易需求承诺需求承诺是指开发方和客户方的责任人对经过了正式技术评审的作出承诺，该承诺具有商业合同的效果。 需求承诺的“八股文如下： 本建立在双方对需求的共同了解根底

23、之上，我赞同后续的开发任务根据该开展。假设需求发生变化，我们将按照“变卦控制规程执行。我明白需求的变卦将导致双方重新协商本钱、资源和进度等。甲方签字 乙方签字人们在作出承诺之前务必要仔细阅读文档，一定要明白签字意味着什么。需求跟踪需求跟踪的目的是建立与维护“需求设计编程测试之间的一致性，确保一切的任务成果符合用户需求。 需求跟踪有两种方式： 正向跟踪。检查中的每个需求能否都能在后继任务成果中找到对应点。 逆向跟踪。检查设计文档、代码、测试用例等任务成果能否都能在中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵即表格。需求跟踪矩阵保管了需求与后继任务成果的对应关系需求变卦控制需求发生变卦的原因主要有： 随着工程的进展，人们包括开发方和客户方对需求的了解越来越深化。原先的需求文档能够存在这样那样的错误或缺乏，因此要变卦需求。 市场发生了变化，原先的需求文档能够跟不上当前的市场需求，因此要变卦需求。 提出需求变卦的动机是好的，目的是希望产品更加符合用户的需求。对工程开发小组而言，变卦需求意味着要调整资源、重新分配义务、修正前期任务成果等，开发小组要为此付出较重的代价。假设每次需求变卦恳求都被采用的话，这个工程也许永远不能按时完成。 需求变卦控制的目的： 假设需求变卦带来的益处大于害处，那么允许变卦，但必