java技术文档.ppt

java技术文档.ppt

《java技术文档.ppt》由会员分享，可在线阅读，更多相关《java技术文档.ppt（43页珍藏版）》请在冰豆网上搜索。

技术文档编写,天津中软卓越,主要内容,项目概述,项目的开发计划文档,项目的需求分析文档,详细设计文档,项目概述,项目的名称确定项目名称项目的背景和目的主要说明项目的来历，和一些需要项目团队成员知道的相关情况。

基本需求的获取确定系统应该具备的主要功能是什么？

这里只需要总结出系统的基本功能需求，更详细的需求要在需求分析阶段完成。

了解项目,项目概述,系统构架的初步设想,Web:

html/AJAX/FLASH/Siverlight,ORMJAVA:

Hibernate,SQLServerOracle,关系型数据库设计范式,数据结构-算法,UI设计,客户端,应用层,数据库,V（视图）C（控制）M（模型）,领域驱动开发（DDD）测试驱动开发（TDD）,JAVA:

Spring,Struts,项目概述,角色划分,软件开发（TW）,软件测试（TEST）,技术文档写作（TW）,完成软件的需求分析、设计、编码、测试和系统部署等工作。

完成测试策略和测试计划的制定，测试用例的设计和执行、最终完成测试评估工作。

完成软件项目开发过程中的技术文档编写工作。

项目实施方法,项目概述,阶段划分：

项目启动与计划项目的需求分析系统与测试设计编码与测试执行测试评估和系统部署,项目的启动和计划,项目的启动可行性分析项目的计划系统项目计划书项目实施的启动项目启动会会议记录,项目的启动和计划,系统项目计划书,项目经过项目启动并确认立项后进入计划阶段。

项目计划的主要任务是根据客户对软件或系统的详细要求，对项目的具体实施进行规划。

主交付物系统项目计划书是对全体项目参与人员对共同遵守的约定，也是项目取得成功的关键文档。

在这个文档中，要对软件开发的全部工作进行详细安排。

例如对每个技术文档的交付时间作出规定，确定技术文档编写的工作目标等。

项目的启动和计划,系统计划制定的简单步骤：

收集和分析资料提炼开发项目的背景，开发的目的和项目目前面临的问题。

确定本项目的可交付成果，以及为提交这些可交付成果必须展开的工作。

确定项目开发所需要的环境、工具。

确定项目的验收标准。

确定项目实施的组织方案，包括参与人员的组织结构、协作和沟通方法。

确定具体任务的先后顺序，所用资源和时间，并制定进度计划。

确定版本控制和问题追踪步骤全体成员审批项目计划书，修改并定版。

本章作业,1,2,3,交付物：

公司请假系统项目计划书,交付形式：

Word文档,提示：

重点列出以下内容：

项目的范围包括哪些？

有哪些可交付的成果？

简要描述项目的开发环境和工具为了开发这个项目，项目的组织结构方式是怎样的？

简要说明项目的时间进度计划项目可能遇到哪些风险？

风险的应对措施有哪些？

项目开发过程中如何进行版本控制和问题追踪？

项目的需求分析,什么是需求,用户的声音,用户的期望,用户的需求,产品系统的需求,宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。

项目的需求分析,需求的重要性,FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：

开发软件系统最困难的部分就是准确说明开发什么。

最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。

此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

软件项目中百分之四十至百分之六十的问题都是在需求阶段埋下的“祸根”,项目的需求分析,需求的重要性,项目的需求分析,需求的层次,业务需求,产品视图和项目范围,用户需求,UseCase,质量属性,功能需求,非功能需求,需求规格说明,项目的需求分析,需求工程,把所有与需求直接相关的活动通称为需求工程,项目的需求分析,需求开发需求调查需求分析需求定义需求管理需求确认需求跟踪需求变更控制,需求规格说明书,需求跟踪矩阵（RTM）,项目的需求分析,需求工程-需求开发,需求开发的目的是通过调查和分析，获取用户需求并定义产品需求。

需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生。

需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。

需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生，以便开展系统设计工作。

项目的需求分析,需求开发-需求调查,确认需求调查的方式,项目的需求分析,需求开发-需求分析,需求建模单一来看需求并不能提供对需求的完全理解可以增强你对系统需求的理解在项目的参与者之间，对于某些类型的信息，图形化交互比文本交互更高效在不同的开发组成员之间扫清语言和词汇上的障碍需求建模的方法1.实体联系图2.数据流程图3.状态转换图,项目的需求分析,需求开发-需求分析,实体联系图:

有助于对业务或系统数据组成的理解和交互,项目的需求分析,需求开发-需求分析,数据流程图:

数据流程图以符合一定规则的图形来表达业务系统中信息的变换和传递过程,项目的需求分析,需求开发-需求分析,状态转换图:

有助于开发者理解系统的预期行为，它对于检查所要求的状态和转换是否已全部正确地写入功能需求中也是一种好方法,项目的需求分析,需求开发-需求定义,好的的特点1.完整性:

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

2.正确性:

每一项需求都必须准确地陈述其要开发的功能。

做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。

若软件需求与对应的系统需求相抵触则是不正确的。

只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。

项目的需求分析,需求开发-需求定义,好的的特点3.可行性:

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

为避免不可行的需求，最好在获取需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

4.划分优先级:

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。

如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。

项目的需求分析,需求开发-需求定义,好的的特点5.无二义性:

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

6.可验证性:

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。

一份前后矛盾，不可行或有二义性的需求也是不可验证的。

项目的需求分析,需求开发-需求定义,和的主要区别和联系1.前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。

2.后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。

3.两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。

软件开发人员应当依据产品需求规格说明书来开发当前产品。

项目的需求分析,需求工程-需求管理,需求管理-小故事-“我终于实现了库存报告中重排序的功能。

”A在项目的每周例会上说。

-“噢，用户在两周前就取消这个功能了。

”项目管理者说，“你没看改过的软件需求规格说明吗？

”-“开发工作进展如何，A?

”，在一次项目状态检查会上项目经理PM问道。

-“我没有按计划执行”A说，“我正在应B的要求添加一个销售分类查询功能，比我原先预计的工作量超期多了。

”-PM似乎有点迷惑，“好像在最近的变更控制委员会的会议中我们没有讨论过这个功能。

B是通过变更过程来提交要求的吗？

”-“没有，她直接给了我这个建议，”A说，“本该请她通过正式渠道的，但这个功能看上去较简单，所以当时我就答应她了。

这个功能其实并不简单，每次当我认为该完工了，但总能意识到在另一个文件中漏了一个变更，所以不得不修改它，再测试一遍。

原以为花4个小时就可以了，实际上花了4天时间，造成我没能按计划完成任务。

我知道延误了工期，那我应该加上这个功能还是放弃它呢？

”,项目的需求分析,需求工程-需求管理,需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。

需求确认的目的是开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

需求跟踪的目的是通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

需求变更控制的目的是指依据规定的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

项目的需求分析,需求确认-需求评审,参与者1.正在评审的项目的规格说明编写者2.真正的用户保证软件需求规格说明能正确并完整地描述了他们的需求。

3.要根据正在审查的文档来开展工作的人们对于一个软件需求规格说明，你可能需要包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员，他们的工作基础都是软件需求规格说明。

这些审查人员将会发现不同类型的问题。

一个测试人员很可能会发现一个不明确的需求，而一个开发人员将会发现一个技术上不可实现的需求。

项目的需求分析,需求确认-需求评审,每个成员的角色1.作者创建或维护正在被审查的产品。

2.协调者（Moderator）与作者一起为审查制订计划，协调各种活动，并且推进审查会的进行。

3.审查员对于一份需求规格说明，审查员对需求给出注解或一个简短评论。

其它审查员可能有不同的解释，这将有利于发现二义性或可能的错误。

4.记录员用标准化的形式记录在审查会中提出的问题和缺陷。

记录员必须仔细审查所写的材料以确保记录的正确性,项目的需求分析,需求确认-需求评审,审查过程阶段,项目的需求分析,需求确认-需求承诺,需求承诺是指开发方和客户方的责任人对通过了正式评审的产品需求规格说明书作出承诺，该承诺具有商业合同的效果。

开发方和客户方的责任人在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么,项目的需求分析,需求跟踪,需求跟踪矩阵（RTM-RequirementsTraceabilityMatrix）需求跟踪矩阵可以定义各种系统元素类型间的一对一，一对多，多对多关系。

允许在一个表单元中填入几个元素来实现这些特征。

例如：

1.一对一:

一个代码模块应用一个设计文档。

2.一对多:

多个测试用例验证一个功能需求。

3.多对多:

每个设计实例对应多个功能性需求,项目的需求分析,需求跟踪,需求的状态：

项目的需求分析,需求变更控制,需求变更的起因1.随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。

原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。

2.市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。

需求变更控制的目的：

如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。

如果需求变更带来的坏处大于好处，那么拒绝变更。

项目的需求分析,需求变更控制,需求基线版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合版本控制要解决的问题根据不同用户的需要配置不同的系统；保存系统老版本，为以后调查问题使用；建立一个系统新版本，使它包含某些决策而抛弃另一些；支持两位以上工程师同时在一个项目中工作；高效存储项目的多个版本。

典型工具:

VSS,CVS,项目的需求分析,需求变更控制-变更影响分析,影响分析是需求管理的一个重要组成部分。

影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。

通过对变更内容的检验，确定对现有的系统做出是修改或抛弃的决定，或者创建新系统以及评估每个任务的工作量。

进行影响分析的能力依赖于需求跟踪矩阵的质量和完整性。

CCB（ChangeControlBoard）变更控制委员会变更控制委员会可以由一个小组担任，也可