《项目开发一般流程分解优秀PPT.ppt》由会员分享，可在线阅读，更多相关《项目开发一般流程分解优秀PPT.ppt（37页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、WEB项目开发的一般流程总纲1.需求分析的确定(最重要)2.架构与设计架构分析与设计业务逻辑分析业务逻辑设计界面设计3.开发环境搭建4.开发-测试-开发-测试5.培训文档编写开发的一般流程需求分析为什么需求分析 需求分析是指理解用户需求，就软件功能与客户达成一样，估计软件风险和评估项目代价，最终形成开发支配的一个困难过程，在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到相关的需求文档，需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家确定要对需求分析具
2、有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.需求分析的任务 需求分析的任务就是解决“用户要做什么”的问题,就是要全面地理解用户的各项要求,并精确地表达所接受的用户需求，并且能够依据自己对用户需求的理解，劝告并诱导客户剔除不合理的需求。需求分析过程需求分析过程需求分析过程需求分析过程需求开发过程域 需求开发过程域 需求开发的目的是通过调查与分析，获得用户需求并定义产品需求。需求调查的目的是通过各种途径获得用户的需求信息（原始材料），产生用户需求说明书。需求分析的目的是对各种需求信息进行分析，消退错误，刻画细微环节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类
3、。需求定义的目的是依据需求调查和需求分析的结果，进一步定义精确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。需求管理过程域需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一样性，并限制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更限制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更
4、失去限制而导致项目发生混乱需求开发过程中困难学问技能问题 行业学问是无穷无尽的。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手生疏的业务时，他该怎么办？首先他要有志气做事，否则连实践的机会都没有。其次他应当抓紧补习这一领域学问，不论是通过自学还是培训的方式，否则他很难与用户沟通。假如可能的话，开发方最好请既懂软件又懂应用域学问的行家来帮忙。需求开发过程中困难看法问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，莫非用户不该告知我们应当开发什么吗？
5、假如用户说不清晰需求，或者常常变更需求，这类问题是用户产生的，应当由他们自己负责。用户说不清晰需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获得精确而细致的用户需求，假如做不到就是失职，不要找借口。合作关系 假如需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很乏累。倘如用户不能很好地协作需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们
6、的问题，讲了该讲的。我们付钱给你们，莫非还要我服侍你们不成？我还要干自己的事情，别打搅我了。你们自己想方法把活干好吧。需求分析员不是销售人员，他们不行能象销售人员那样通过某些手段笼络住用户就能成功。精彩的需求分析员不仅要有过硬的专业学问，还要具备较强的沟通、沟通实力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、困难的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能削减今后的摩擦。假如条件允许的话，开发方最好为
7、用户举办关于需求工程的培训，这样的培训将运用户明白需求的重要性以及忽视需求的危害性，从而促使他们主动友善地参与需求工程中的各项活动。用户在需求工程中的“权利”用户在需求工程中的“权利”1.有权要求开发方派遣资质合格的需求分析员和相关人员。2.有权要求开发方接受用户熟悉的语言来描述需求，即开发方必需供应用户看得懂得需求文档。3.有权审查需求文档，并对有争议的需求作出决策。假如认为需求文档不能精确地反映用户真实的意愿，可以拒绝在需求文档上签字。4.假如用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户确定是否变更需求。用户在需求工程中的“义务”用户在需求工程中的“义务
8、”1.以主动友善的看法与开发方人员沟通、协作，尽可能地为开发方人员供应工作和生活上的便利。2.乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。3.在不泄漏机密的前提下，尽可能地向需求分析员供应与需求相关的材料。4.与需求分析员共同评审需求文档，确保需求文档精确地反映用户真实的意愿。5.对专业性太深化的学问领域，用户有义务组织开发人员进行简洁的培训。需求没有做好的后果 如何准备调查需求需求分析员应当确定需求调查的方式，例如：与用户负责人交谈，向用户提问题。同将来此软件的目标用户交谈，了解他们的目前的工作状况.参观用户的工作流程，视察用户的操作。与同行、专家交谈，听取他
9、们的看法。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。如何做好需求分析为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户恒久是正确的。谁都知道这不是真的。事实上，很多时候用户说不清晰需求、会说错需求或者提出一些无法实现的需求。需求分析是指在需求开发过程中，对所获得的需求信息进行分析，刚好解除错误和弥补不足，确保需求文档正确地反映用户的真实意图。需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简洁易用（保你一学就会），很有
10、好用价值。“问答分析法”比较适合于用户需求调查阶段“建模分析法”比较适合于产品需求定义阶段。问答分析方法问答分析方法 问答分析方法很简洁：刨根究底地问，假如问题都被解答了，那么需求也就分析清晰了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。问答分析最重要的问题是：“是什么”,”做什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，假如“是什么”的内涵不够清晰，则应补充说明“不是什么”。假如“是什么”和“不是什么”并不是“天经地义”的，那么应当说明“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清晰的需求。其它常见的问题有：需求存在二义性吗？
11、需求文档的上下文有冲突吗？需求完备吗？需求是必要的吗？需求可实现吗？需求可验证吗？需求的优先级确定了吗？建模分析法人们都有这样地感受：有些时候用语言描述某个问题特殊费劲，而接受图形则使人一目了然.在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面对对象分析法”。恰当地运用图形符号：现代建模工具如Rose、Jude有特别丰富的图形符号和文字标注，能很好地表达模型的细微环节。要留意的是：在建模时运用花样过多的图形符号或文字意味着模型表示的困难
12、化，将使开发人员更难驾驭，而且使图形文档更加杂乱。世上不存在一个应有尽有的图它能完整地描述需求。需求建模不行能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、说明作用。建议将模型存放在需求文档的附录中，便于正文引用。分析决策当需求从四面八方收集来后，需求的冲突在所难免。对于那些难以达成共识的需求而言，常常会发生“公说公有理，婆说婆有理”的现象。那么需求分析员原委应当听谁的呢？假如一群人对需求有争议，并不是谁声音最响就听谁的。依据生活阅历，最保险的方法是：先听官儿大的或者威望高的，假如大家的职位和威望都差不多，那么接受“少数听从大多数”的原则。假如一个产品可以卖给几类客户，但
13、是各类客户都要求产品依据他们的喜好来开发。此时对需求的决策应当以商业利益为导向，即哪一类客户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。当开发者想象中的产品与客户所提的需求有冲突时，一般应当敬重客户的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当订正明显不合理的客户需求。假如产品很困难，双方都不太明白需求，此时最好请开发人员快速构造软件的原型，双方看着软件原型再分析需求什么是好的需求规格说明书正确 需求规格说明书应当正确地反映用户的真实意图，“正确”是产品需求规格说明书最重要的属性。假如“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发
14、者和用户自己都不明白用户原委“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必需对需求规格说明书进行确认。清晰 清晰的需求让人易读易懂。清晰的反义词是“难读”、“难理解”。你可以接受反问的方式来推断需求文档是否清晰：文档的结构、段落是否一塌糊涂？上下文是否不连贯？文档的语句是否模糊其词、罗里罗嗦？看了半天是否还不明白需求原委是什么？无二义性 “无二义性”是指每个需求只有唯一的含义。假如一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。假如需求存在二义性，将会导致人们误会需求而开发出偏离需求的产品。为了使需求无二义性，人们在写产品需求规格说明书时措词应当精确，切勿模棱两可
15、。什么是好的需求规格说明书一样 “一样”（Consistent）是指产品需求规格说明书中各个需求之间不会发生冲突。冲突常常潜藏在需求文档的上下文中。必要 产品需求规格说明书中的各项需求对用户而言应当都是必要的。可以把“必要”比方为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”明显是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，假如条件允许则再做“锦上添花”的需求。为了避开主次颠倒，应当在产
16、品需求规格说明书中将那些“锦上添花”的需求设置为较低的优先级。什么是好的需求规格说明书完备“完备”（Complete）是指产品需求规格说明书中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。不完备的产品需求规格说明书将导致产生功能不完整的软件，用户在运用该软件时可能无法完成预期的任务。什么是好的需求规格说明书可实现 产品需求规格说明书中的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”
17、。吹牛皮虽然不犯法，但是产品需求规格说明书可是白纸黑字啊。经过双方确认的产品需求规格说明书相当于商业合同，假如开发方不能够实现产品需求规格说明书中的内容，那就是违约，可能会被罚款的。对于合同项目，假如开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一样的处理看法，避开将来发生商业纠纷。什么是好的需求规格说明书可验证 产品需求规格说明书中的各项需求对用户方而言应当都是可验证的（Verifiable）。假如需求是不行验证的，那么用户就无法验收软件，可能会发生商业纠纷。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师
18、，他怎能造个十二级台风来试验？假如双方都认可“接受计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的什么是好的需求规格说明书确定优先级 为什么要确定需求的“优先级”？理论上讲，软件的全部需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚起先的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。人们想出了“取舍”方法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由
19、用户和开发方共同确定需求的优先级。什么是好的需求规格说明书阐述“做什么”而不是“怎么做”产品需求规格说明书的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。假如在调查、定义需求时想好了“怎么做”，当然应当写下来，否则岂不奢侈！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。如何定义产品需求第一步：细化并分析用户需求第一步：细化并分析用户需求 需求分析员首先对用户需求说明书进行
20、细化，对比较困难的用户需求进需求分析员首先对用户需求说明书进行细化，对比较困难的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如接受行建模分析，以帮助软件开发人员更好地理解需求。例如接受Rational Rational 的的RoseRose工具进行需求的建模分析，建模分析产生的文档可以作为产品需求规工具进行需求的建模分析，建模分析产生的文档可以作为产品需求规格说明书的附件。补充说明：建模分析的技术难度比较高，需求分析员应格说明书的附件。补充说明：建模分析的技术难度比较高，需求分析员应当依据自身水平进行取舍。当依据自身水平进行取舍。其次步：撰写产品需求规格说明书其次步：撰写产品需求
21、规格说明书 需求分析员依据指定的文档模板撰写产品需求规格说明书。假如待开发需求分析员依据指定的文档模板撰写产品需求规格说明书。假如待开发的产品分为软件和硬件两部分的话，则应当撰写软件需求规格说明书和的产品分为软件和硬件两部分的话，则应当撰写软件需求规格说明书和硬件需求规格说明书。硬件需求规格说明书。第三步：进行需求确认第三步：进行需求确认项目经理邀请同行专家和用户（包括客户和最终用户）一起评审产品需求项目经理邀请同行专家和用户（包括客户和最终用户）一起评审产品需求规格说明书，尽最大努力使产品需求规格说明书能够正确无误地反映规格说明书，尽最大努力使产品需求规格说明书能够正确无误地反映用户的真实意
22、愿。用户的真实意愿。需求评审之后，开发方和客户方的责任人对产品需求规格说明书作书面需求评审之后，开发方和客户方的责任人对产品需求规格说明书作书面承诺。承诺。需求文档用户需求说明书与产品需求规格说明书的主要区分与联系前者主要接受自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够具体。后者是前者的细化，更多地接受计算机语言和图形符号来刻画需求，产品需求是软件系统设计的干脆依据。两者之间可能并不存在一一影射关系，因为软件开发商会依据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被安排到软件的数个版本中。软件开发人员应当依据产品需求规格说明书来开发当前产品。需求
23、确认（评审和承诺）需求确认（评审和承诺）需求确认是指开发方和客户方共同对产品需求规格说明书进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。人们在沟通的时候，常常会发生“问非所求，答非所问”的事情，用户表达的需求，不同的开发人员可能有不同的理解。假如需求分析员误会了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能避开：有个外星人间谍潜藏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。好玩的是，车里住着一种叫作人的寄
24、生虫，这些寄生虫完全限制了车。”不论是困难的项目还是简洁的项目，需求分析员和用户都有可能误会需求。所以需求确认工作（属于需求管理）必不行少需求评审面临的困难需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚起先评审时，大家都比较细致，越到后头越马虎。需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不简洁（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把全部事情挤在一块做，需求开发是按部就班的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参与评审的人员也少一些，组织会议就比较简洁需求承诺需求承诺是指开发方和客户方的责任人对通过了正
25、式技术评审的产品需求规格说明书作出承诺，该承诺具有商业合同的效果。需求承诺的“八股文”如下：本产品需求规格说明书建立在双方对需求的共同理解基础之上，我同意后续的开发工作依据该产品需求规格说明书开展。假如需求发生变更，我们将依据“变更限制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。甲方签字 乙方签字人们在作出承诺之前务必要细致阅读文档，确定要明白签字意味着什么。需求跟踪需求跟踪的目的是建立与维护“需求设计编程测试”之间的一样性，确保全部的工作成果符合用户需求。需求跟踪有两种方式：正向跟踪。检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。逆向跟踪。检查设
26、计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。不论接受何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系需求变更限制需求发生变更的起因主要有：随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深化。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。市场发生了变更，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新安排任务、修改前期工作成果等，开发小组
27、要为此付出较重的代价。假如每次需求变更恳求都被接受的话，这个项目或许恒久不能按时完成。需求变更限制的目的：假如需求变更带来的好处大于坏处，那么允许变更，但必需依据已定义的变更规程执行，以免变更失去限制。假如需求变更带来的坏处大于好处，那么拒绝变更。需求变更限制过程中最难办的事情是莫过于“拒绝客户提出的需求变更恳求”。通常状况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入逆境。解决这个问题最好的方法是事先建立“游戏规则”：开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；假如客户第四此变更需求，开发方有权拒绝，除非客户情愿补偿开发方的损失。WEB项目开
28、发的一般流程分析与设计之架构分析与设计架构分析与设计逻辑架构3层架构、n层架构MVCModel 1 or Model 2物理架构Web服务器的分布数据库服务器的分布技术解决方案的确定Java/.NETOpen Source/商业WEB项目开发的一般流程分析与设计之业务逻辑分析业务逻辑分析依据需求分析业务逻辑有哪些人会运用本系统他们会运用本系统做什么通常他们运用本系统的步骤是什么样的会有哪些明显的类来支撑本系统的运行会有哪些不同的提示会返馈给用户本阶段与需求的确定亲密相关，通常在确定需求的时候就会进行相关的分析WEB项目开发的一般流程分析与设计之业务逻辑设计业务逻辑设计依据需求的分析来确定具体的类确定类的属性确定类的接口（方法）确定类之间的关系确定用户操作流程在设计上的反映进行数据库的设计不同的项目步骤可能不尽相同WEB项目开发的一般流程分析与设计之界面设计界面设计设计系统的界面风格颜色、style设计系统的具体“模拟”界面能够从头走到尾便利进行需求的确定便利JSP程序员的开发WEB项目开发的一般流程开发环境搭建开发环境搭建开发工具的确定配置管理工具的确定测试工具的确定文件服务器/配置服务器等的确定WEB项目开发的一般流程开发开发-测试-开发-测试依据设计进行开发快速开发原型进行迭代开发提早进行测试单元测试黑盒测试性能测试易用性测试