开发一般流程

WEB项目开发的一般流程—总纲1.需求分析的确定(最重要)2.架构与设计①架构分析与设计②业务逻辑分析③业务逻辑设计④界面设计3.开发环境搭建4.开发-测试-开发-测试5.培训文档编写开发的一般流程—需求分析为什么需求分析需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程，在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到相关的需求文档，需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.需求分析的任务需求分析的任务就是解决“用户要做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求，并且能够根据自己对用户需求的理解，劝说并诱导客户剔除不合理的需求。需求分析过程需求分析过程需求开发过程域需求开发过程域需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。需求管理过程域需求管理过程域需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱需求开发过程中困难知识技能问题行业知识是无边无际的。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他该怎么办？首先他要有勇气做事，否则连实践的机会都没有。其次他应当赶紧补习这一领域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。需求开发过程中困难态度问题相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。合作关系如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧……。需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。用户在需求工程中的“权利”用户在需求工程中的“权利”1.有权要求开发方派遣资质合格的需求分析员和相关人员。2.有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。3.有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。4.如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。用户在需求工程中的“义务”用户在需求工程中的“义务”1.以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。2.乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。3.在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。4.与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。5.对专业性太深入的知识领域，用户有义务组织开发人员进行简单的培训。需求没有做好的后果如何准备调查需求需求分析员应当确定需求调查的方式，例如：与用户负责人交谈，向用户提问题。同未来此软件的目标用户交谈，了解他们的目前的工作状况.参观用户的工作流程，观察用户的操作。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。如何做好需求分析为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。“问答分析法”比较适合于用户需求调查阶段“建模分析法”比较适合于产品需求定义阶段。问答分析方法问答分析方法问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。问答分析最重要的问题是：“是什么”,”做什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。其它常见的问题有：需求存在二义性吗？需求文档的上下文有矛盾吗？需求完备吗？需求是必要的吗？需求可实现吗？需求可验证吗？需求的优先级确定了吗？建模分析法人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然.在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。恰当地使用图形符号：现代建模工具如Rose、Jude有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。分析决策当需求从四面八方收集来后，需求的冲突在所难免。对于那些难以达成共识的需求而言，经常会发生“公说公有理，婆说婆有理”的现象。那么需求分析员究竟应该听谁的呢？如果一群人对需求有争议，并不是谁声音最响就听谁的。根据生活经验，最保险的办法是：先听官儿大的或者威望高的，如果大家的职位和威望都差不多，那么采用“少数服从大多数”的原则。如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策应当以商业利益为导向，即哪一类客户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。当开发者想象中的产品与客户所提的需求有冲突时，一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当纠正明显不合理的客户需求。如果产品很复杂，双方都不太明白需求，此时最好请开发人员快速构造软件的原型，双方看着软件原型再分析需求什么是好的需求规格说明书正确需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。清楚清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：文档的结构、段落是否乱七八糟？上下文是否不连贯？文档的语句是否含糊其词、罗里罗嗦？看了半天是否还不明白需求究竟是什么？无二义性“无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。什么是好的需求规格说明书一致“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。必要《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。什么是好的需求规格说明书完备“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。什么是好的需求规格说明书可实现《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被