项目开发流程介绍

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,项目开发流程,目录,团队组建与项目计划,需求管理与配置管理,项目规范与软件设计,软件测试,验收交付与过程改进,确定分组和小组分工,确定设计项目所用的工具和技术,制定系统开发计划,了解团队在软件开发过程中的重要作用,了解常见软件开发团队的角色和分工,学会制定软件开发计划的原则、方法,需要解决的问题,假如，现在的你正在参加面试，面试官问你如下问题,你能读懂项目计划么？,你有过团队开发经验么？,你能读懂需求规格说明书么？,你对测试了解多少，会写测试用例么？,你用,Java/.NET,做过中小型项目开发么？,请你说说一个项目中都应该有哪些规范？,你做过设计么，如果做过谈谈这些设计吧？,.,项目的特征,项目的一次性,一次性是项目区别其他任务的基本特征,项目目标的明确性,成果性目标,约束性目标,项目的整体性,项目是为实现目标而开展任务的集合，不是一项项孤立的活动,1,、项目的一次性。,一次性是项目区别其它任务（比如：组装汽车）的基本特征。这意味着每个项目都有它的特殊之处，不存在两个完全相同的项目。,2,、项目目标的明确性。,项目作为一类特别设立的活动有其明确的目标，一般由成果目标和约束性目标组成。其中，成果性目标是项目的来源（比如：给中国电信的一套计费系统）；约束性目标又称限制条件，是实现成果性目标的客观条件（比如：项目开发过程中要遵循国家法律法规）和人为约束目标（比如：项目组成员的去留和项目的最后期限）的统称，是项目实施过程中必须遵守的条件，从而成为项目实施过程中的主要目标。,3,、项目的整体性。,项目是为实现目标而开展任务的集合，它不是一项项孤立的活动，而是一系列活动的有机组合，从而形成一个完整的过程。强调项目的整体性也就是强调项目的过程性和系统性。,项目的属性是项目所固有的，是区别于其它活动的根本原因。,常见的软件开发团队组织形式,1,、小型软件公司团队组织结构,2,、微软公司团队组织结构,3,、大型软件公司团队组织结构,第一种：,小型软件公司团队组织结构。如图,1.7,所示，在小型软件公司中，人员配置精简实用。由项目经理直接带领开发经理、质量保证工程师、开发工程师和测试工程师来完成项目。,这种组织结构的好处在于分工灵活，但同时每个人也是一个“多面手”，例如，开发经理既要有很强的技术，也要有相应的管理经验；开发工程师除了进行程序开发，也要懂得数据库设计开发，并且要了解一些软件测试知识。而且通常是一个人担负多个角色，团队中的每个人几乎都要担负开发工程师和测试工程师的职责。,第二种：,微软公司团队组织结构。如图,1.8,所示，微软公司的团队组织结构可以说是相当完善了，这种组织结构中，各团队人员分工很细致，而且权责明确，人员之间的接口明确。只是构建这种项目团队的成本太高。,第三种：,大型软件公司团队组织结构。如图,1.9,，这种组织结构中，人员配置比较齐备，计划,/,需求,/,设计,/,开发,/,测试,/,验收各个阶段都有专人负责。但同时人员组织分成了四层，给管理上增加了困难。,建议采取的团队结构,每小组,45,人,小组所有成员都担任,开发工程师,和,测试工程师,职责,每小组都设置一个,项目经理,（小组长）、,开发经理,（技术负责人）和一个,质量保障工程师,（负责版本控制工具,CVS/SVN/VSS,的使用）,我们将采用,第一种,，既,小型软件公司团队组织结构,。其中每个角色的职责定义为：,项目经理（,PM,，,Project Manager,）,：项目负责人。一般来讲，项目经理的职责包括：承担责任；需求管理；协调、组织、解决团队问题；控制进度，获取并调配资源（分配任务）；召集会议；做出决定；风险控制，解决危机；考核团队成员。在我们的毕业设计中，项目经理（小组长）要协调组织大家完成项目，定期检查大家的进度等。,开发经理（,TTL,，,Team technology,Leadr,）,：技术负责人。一般开发经理的职责包括：架构设计（技术决策）；参与需求管理；在技术上训练并指导团队；召集技术会议；组织团队培训；记录团队成员技能提升等。在我们的毕业设计项目中，开发经理要主动帮助技术上有困难的同学，但不能帮他做。,质量保证工程师（,QA,Quality Assessment,）,：一般负责配置管理，有效地控制各种项目文档和代码当前版本的唯一性；按照发布计划获得并发布版本，提交测试；过程控制和质量保证等。,开发工程师（,SE,，,Software Engineer,）,：按照需求规格说明书的描述和项目规范开发程序代码，实现功能，修正开发过程中产生的缺陷。,测试工程师（,TE,，,Testing Engineer,）,：根据需求规格说明书的描述和项目规范对发布的版本软件进行黑盒测试，发现并报告软件缺陷，督促开发工程师修正缺陷。,制定项目计划的二个原则,有效追踪原则（任务点划分）,对任务进行有效分解,粒度适中（一般控制在,1,3,个人日）,共同参与原则,不是,PM,一个人的事,共同估计工作量，并作出承诺,财务管理系统,任务点划分,费用管理,所有费用,增加收入,增加支出,费用类型,报销人,费用统计,用户管理,增加用户,登陆信息,本章任务,画出“财务管理系统”用例图,使用用例的方式准确描述“权限管理系统”需求,使用,CVS,或,SVN,管理项目文档,前置条件：用户（包含普通用户和系统管理员）在系统首页输入用户名和密码。,事件流：,用户在系统首页输入用户名和密码，点击“登录”按钮时用例开始。,.,后置条件：“会话”（,session,）中保存了已登录用户的信息及其拥有的权限。,学会用例图的画法,学会使用用例的方式描述软件需求,学会使用静态原型法定义软件需求,了解配置管理的概念和重要意义,学会使用,CVS/SVN,进行版本控制,为什么要做需求管理,1,、客户知道自己要什么，但表达不清。,有时候客户有自己的,IT,团队，这时候情况稍好，大家讲相同的“语言”沟通会相对顺畅。但很多时候，客户知道哪些数据和信息需要通过系统管理，需要系统给业务什么样的支持，但他们只能用自己行业的语言来表达。这时候首先需要我们对其行业和业务都要有一个理解，然后我们才可以设计信息系统，并给客户确认。,任何一个具有一定规模的信息化系统都会涉及很多人，很多岗位和角色。在调研的时候，对这些人我们都需要访谈。每个岗位都有自身的立场、眼界和利益，对系统需求的描述也会出现相左的情况。这也是需要权衡处理的。,2,、客户不知道自己要什么。,有的时候，客户期望通过信息化系统提高企业的效率。但具体怎么做就了解不多了。这时候需要我们去主动地发掘需求，同时需要我们的行业经验来支撑。,所以，我们要做需求管理。,在软件生命周期中，计划完成后，第一项实质性的阶段就是需求阶段。在需求阶段结束的时候，我们需要得到一个,准确的，经过客户确认,的,需求规格说明书,需求规格说明书,概念,软件开发项目中用于,明确定义系统需求,的文档。,需求规格说明书的作用,开发者与用户间事实上的技术合同书,开发者下一步设计和编码的基础,测试验收目标系统的依据,功能性需求：,用来描述系统所应提供的功能和服务,系统功能,输入输出,异常,非功能性需求：,不直接与系统的具体功能相关的一类需求,安全性,可扩展性,响应时间,1,、功能性需求,简单地说，功能性需求用来描述系统所应提供的功能和服务。包括系统应该提供的服务、对输入如何响应及特定条件下系统行为。对于用户需求（客户对系统的要求），用较为一般的描述给出；对于功能性的系统需求，需要详细地描述系统功能、输入和输出、异常等有时，功能需求还包括系统不应该做的事情。功能需求取决于软件的类型、软件的用户及系统的类型等。,系统的功能性需求应该具有全面性和一致性。全面性意即应该对用户所需要的所有服务进行描述，而一致性则指需求的描述不能前后自相矛盾。在复杂的大型系统中，做到这两点会有一定困难。但只有做到了这两点，才能保障我们项目的顺利进行。,2,、非功能性需求,非功能需求是指那些不直接与系统的具体功能相关的一类需求，它们与系统的总体特征相关，如可靠性、可扩展性、安全性、响应时间等，甚至包括界面易用程度和文档、代码规范性的要求。非功能需求定义了对系统提供的服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。它源于用户的限制，包括预算的约束、机构政策、与其他软硬件系统间的互操作，以及如安全规章、隐私权保护的立法等外部因素。,与关心系统个别特性的功能需求相比，非功能需求关心的是系统的整体特性，因此对于系统来说，非功能需求更关键。一个功能需求得不到满足会降低系统的能力，但一个非功能需求得不到满足则有可能使系统无法运行。,非功能需求不仅与软件系统本身有关，还与系统的开发过程有关。与开发过程相关的需求包括：对在软件过程中必须使用的质量标准的需求、设计中必须使用的建模工具的需求以及软件过程所必需遵守的原则等。,用例概念,描述系统有哪些人用，和每个人是怎么用的,用例是一种沟通工具,最终用户和开发人员使用它进行交流，并在系统需求上达成共识,用例需要回答的问题,这个系统涉及哪些人？他们对系统有什么期望？,用例是什么？其原始英文是,usecase,，直译过来就成了用例，从字面的直接理解就是使用的例子。用例的定义是：与系统使用者交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。简单的说，用例描述了这个系统有哪些人要用，和每个人是怎么用的。,用例常被用来描述一个系统外在可见的需求情况，常被用作项目的需求分析阶段，对项目的测试计划和用户指南也有用处。他们被用来创建和验证被提议的设计，并确保该设计满足所有的需求。,这里，我们使用用例描述系统功能性需求。,为什么要做配置管理,在实际的项目开发中,工作成果被覆盖了该怎么办？,时间一长，文件版本太多，该如何维护？,两人同时修改了一个程序文件，会不会打架？,对小组成员各自承担的代码统一管理,项目开发小组的成员之间不会发生代码修改冲突,对项目小组各成员所作的修改进行统一汇总,保留修改的轨迹，以便撤销错误的改动,对项目过程中代码的各个版本进行管理,常用的配置管理工具,VSS,（,Visual SourceSafe,）,CVS,（,Concurrent Version System,）,SVN,（,Subversion,）,了解项目规范对软件开发的重要作用,学习数据库规范、编码规范和用户界面规范,确定设计将采用的技术框架,了解常见的数据库规范和编码规范,了解详细设计和概要设计阶段的主要工作,会按照模板编写详细设计文档,会画类图，能读懂时序图,什么是项目规范？,定义：项目规范是一系列标准，规定代码中的变量如何定义，注释如何编写，数据库表如何设计，界面如何组织等。,要点：,范围,：软件项目中,要求,：所有项目组成员都要严格遵守,目的,：统一项目组行为，统一项目产品规格,内容,：一系列规则，包括：数据库规范、编码规范、用户界面规范、测试规范、评审规范等,常见项目规范,(1),数据库规范,数据库设计规范,原则上符合第三范式,必要时可违反第三范式,数据库命名规范,视图名称,存储过程名称,表名称 例：表名称,=,表名前缀,+,下划线“,_” +,表内容标识,系统用户信息表,sys_user_info,编码规范,命名风格,换行缩进的风格,其它,每个类不超过,200,行,每行不超过,60,字符,所有,Action Bean,继承自,BaseAction,，放在,com.cstp.web.action,包下等,需要注意的是，编码规范不仅限于命名规则、缩进和换行、注释。有时候还包括程序结构方面的规定，比如：实体类放在什么包下，一个规范的实体类是什么样子的；,DAO,层的类包含哪些方法，不应该包含什么样的方法；业务逻辑层的代码中可以放什么的代码，绝对不允许放什么样的代码；,Action,代码中不允许描述业务逻辑等。,用户界面规范,界面展现规范,界面风格要一致,例如：统一的色调、统一的字体字号,特定内容的展现格式要一致,例如：日期的格式、数字的格式,交互方式的规范,操作风格要一致,例如：“*”表示必输项,特定内容的输入格式要统一,例如：日期以,1982-02-22,的格式输入,概要设计,系统设计：系统具体的技术方案，与其他系统的接口方式,系统设计需要考虑到：,硬件环境、软件环境、网络环境,用户操作水平,团队技术能力,开发时间限制,结构设计：,确定程序是由哪些模块组成的，各模块分别完成什么样的功能，它们之间存在着什么样的关系。,软件详细设计,(1),详细设计的核心是,将业务模型映射到技术模型,业务模型,技术模型,执行,select,book_name,from,sys_book,where,book_no,= ,书籍编号, and,book_status,= ,已预订, and,book_subscribe_stu_no, ,学生借书卡编号,。如果查询到,1,条记录，则抛出异常，异常信息为：“图书,图书名称,已经被预订，不能借出。”；否则，继续处理。,学生到图书馆申请借书，图书管理员登录图书管理系统。首先，,检查这本书是否已经被预订了，如果已被预订则不能借出。,详细设计还包括,实现某一功能时，具体包含哪些类、方法、类。以及类之间的关系和调用顺序,对应的界面如何展示，如何交互，界面间如何切换,核心算法的伪代码,数据库设计的工作,软件详细设计,-,类图,详细设计中的类图,图中每一个方框表示一个类（或接口），分成三格,第一格：类的名字,第二格：类的属性,第三格：类的方法,空三角箭头：实现关系,虚线箭头：依赖关系,基于框架开发,在软件项目开始编码前，我们已经准备好了：,需求规格说明书,项目规范,概要设计,详细设计,项目框架,我们现在需要做的就是：导入,框架代码,，调试通过。然后直接在此基础上按照,需求规格说明书,，严格遵守项目规范写代码 。,建立软件质量观念,了解软件测试的意义和方法,学会编写测试用例,了解缺陷管理的流程,软件缺陷的定义,软件未达到产品说明书中已经标明的功能,软件出现了产品说明书中指明不会出现的错误,软件未达到产品说明书中虽未指出但应当达到的目标,软件功能超出了产品说明书中指明的范围,软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良,什么是软件测试,定义：软件测试是为了发现软件缺陷而执行程序的过程,软件测试的依据,需求规格说明书（,重中之重,）；,相关的设计说明（概要设计，详细设计等）；,已经基本成型的,UI,（可以有针对性地补充一些用例）。,软件测试方法,(1),按照测试方法来分，软件测试分为：,黑盒测试,白盒测试,软件测试方法,(2),思想,已知程序内部工作流程，通过测试检验程序内部动作是否按规格说明书规定正常运作,依据,程序的内部逻辑结构，针对程序的逻辑路径设计测试用例,特点,必须了解程序的内部工作流程,白盒测试,思想,根据已知程序的功能和性能,(,而不是内部细节,),，通过测试检验每个功能和性能是否正常,依据,程序的功能和性能描述,特点,知道程序的功能和性能，不必了解程序的内部结构和处理细节,软件测试方法,(3),黑盒测试,软件测试阶段,按照测试阶段来分，软件测试分为：,需求分析,概要设计,详细设计,编码,单元测试,集成测试,确认测试,软件开发过程,软件测试阶段,用户需求,验收测试,什么是测试用例,测试用例的定义,测试用例就是一个“情况”，软件程序在这种情况下，必须能够正常运行并且得到预期的结果。,一个简化的测试用例：,用例：,用户登录,前置条件：,用户进入到“用户登录页面”,输入：,合法用户在系统中的用户名和密码,期待结果：,用户提交正确的用户名和密码后，顺利进入系统,测试结果：,成功,/,失败,测试用例的设计原则,对应需求编写测试用例,测试用例要全面覆盖需求规格说明书中的软件功能点,便于发现有价值的缺陷,比如：系统要求上传,2M,以下的文件，一般上载,1M,多一点的文件绝不会有问题。这时“敏感”会让我们设计测试用例时，尽量去注意边界条件，上载,1.9M,的文件会不会出问题？上载正好,2M,的文件呢？上载,2M,多一点的文件呢？,了解项目验收的常见流程,了解项目维护的日常事项,了解过程改进的概念及实践,会给角色分配权限,什么是项目实施？,定义：实施是指将软件系统部署到客户方的计算机上，协助客户准备基础数据，使软件系统顺利上线运行。,项目实施时的准备,保证软件符合需求，质量过关,全面做好测试工作（集成测试、系统测试、性能测试）,制定实施计划,要发布的代码版本、数据库创建方式、基础数据准备方式,准备好程序代码和相关文档,用户手册、测试用例文档,项目验收,客户对系统的“接收测试”,对系统进行范围核实（看看需求是否全部实现）和质量核实,最后，客户在验收报告上签字，一切尘埃落定，每个人都长出一口气，心想“这些琐琐碎碎的单据、报表与我再无瓜葛了”！大中型的项目会有一个签字验收仪式。,维护阶段,系统上线了，项目验收了，,客户使用软件的过程中可能会遇到一些问题,可能的原因包括,软件的原有功能和性能可能不再适应用户的要求,例：,企业业务流程调整,软件的工作环境改变了,例：国家对某些单据的打印规格的规定调整了,软件运行中发现错误，需要修改,例：单据编号发现重号,用户操作不方便，影响效率。,维护阶段做什么？,校正性维护,诊断、校正软件错误的过程,适应性维护,为适应环境的变更（计算机设备更新）而修改软件的维护活动,完善性维护,为满足用户提出的新功能、性能要求而进行的维护,预防性维护,为进一步改进可维护性、可靠性而进行的维护活动,项目交付,项目结束时，开发团队将项目交付到维护团队手中,客户已经签字验收,维护团队对项目检验通过,维护团队要迅速熟悉项目的业务、技术和客户,维护流程,1,、客户提出维护申请,2,、对确实需要修改系统解决的问题进行业务上和技术上的论证,3,、对修改方案论证和审批通过后，报给客户修改和发布的计划,范围管理,严格定义系统的边界，明确什么需要给客户做，什么不需要做,软件需求变更和膨胀是项目的杀手,功能性膨胀,例：客户业务流程（,CRM,和,HR,系统要集成）变化所需系统做调整,非功能性膨胀,例：培训要求、文档要求、性能要求,保持一致性,系统中一个小小的调整，导致牵一发而动全身,