对日软件开发流程.docx

1、对日软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-9018）对日软件开发流程对日软件开发流程日本的软件项目开发非常严格，项目很少出现延期，一旦延期，伴随而来的就是大宗的罚款，因此，日本的软件项目非常重视按期交付。在日本软件项目进度控制中起关键作用的就是软件的阶段定义。日本软件项目阶段分项目提案、要件定义、概要设计、详细设计、编写代码、单体测试、结合测试、系统测试、编写手顺等。项目提案指项目可行性分析、项目立项，是用户需求的正式提出阶段，本阶段出具项目提案书。要件定义指业务需求的详细确定和系统需求的详细确定，系统需求主要包括软件性，运行速度，网络环境

2、，运行环境，架构等方面的要求，以及技术选择的调查，本阶段出具业务要件定义书和系统要件定义书。概要设计指功能设计，系统架构设计，界面设计和数据库设计，其中界面设计和数据库设计涉及内容最多，要求最详细，本阶段出具概要设计定义书、数据库设计定义书和界面设计定义书。详细设计主要指编码前的类设计，类中方法属性设计，类之间调用关系设计，本阶段出具详细设计定义书。编写代码指各模块负责人编写相关代码，在编码之前还要编写单体测试式样书，本阶段出具程序源码和单体测试式样书。单体测试指由各模块编码人员完成各自模块的单体测试工作，单体测试完成要求各模块独立运行时缺陷均消除，本阶段出具单体测试票。结合测试指各模块单体测

3、试完成后，各模块同时运行时，模块之间的运行状况的测试，包括业务流，负载，运行速度，稳定性，一致性等内容，本阶段出具结合测试票。系统测试指系统各模块统一运行缺陷均消除后，模拟用户环境运行的测试过程，本阶段要尽量模拟用户实际平台，用户数量，硬件环境，软件环境，网络状况，用户数据进行系统测试，本阶段出具系统测试票。编写手顺指编写用户手册，本阶段出具安装手顺、使用手顺和维护手顺。对日开发的基本流程中包括了以上11个阶段，每个阶段为一个里程碑，每个里程碑在安排计划时都规定了明确的完成期限，这些阶段性的里程碑是项目进度的关键点。每个阶段完成后必须进行阶段的Review，这种阶段Review起到了阶段验收和

4、总结的作用。阶段Review是日本项目阶段控制的核心。只采用阶段Review的方式进行验收也有其不足之处，所有验收工作都放在阶段完成再进行，阶段中的错误后续持续放大无法得到控制。而且通常情况下，阶段Review时问题会比较多，Review后修改时间比较长，修改次数也较多，造成很大程度的反复工作。再有，对日软件开发过程中，阶段内任务的安排和验收比较；无序，很多问题会被有意推迟到Review时解决。要件定义决定了系统全部的功能，说本阶段产出的成果物左右了整个系统的成败也不为过。输入输出1.顾客的业务需求1.要件定义书2.网络结构定义书要件定义的输入是顾客想要系统化的业务需求。系统的开发是为了顾客企

5、业的业务更灵活及高效。而要件定义的目的就是明确顾客想要系统化的业务逻辑。进行要件定义所需具备的能力当进行上面所说的要件定义时，需要有以下的能力。1.理解顾客企业的商业模型必须要充分理解顾客是如何进行商业活动的。要明白为什么必须系统化，为什么要建立这样的商业模型，要收集各方面的需求，不能有遗漏。因为到后期，当发现需求分析不充分时将导致整个开发的系统都无用。另外，如果做了过多的分析，只要将不用的功能放弃掉就可以，对进度的影响很小。当然，对不需要功能的开发投入的金钱成本，顾客是不需要支付的，全部由开发方负责。2.与顾客谈判的能力与人谈判的能力是指待人能力，协调能力。对方是给钱的顾客，不能用严厉的语言

6、激怒对方。对于无法理解的需求要努力在当时就理解了，对于顾客所要求的不合理的需求要能协调好。这个不像其它的能力可以通过培训或以往的经验来弥补，主要取决于个人的性格，是相当重要的能力。3.进行要件定义的同时，要能想象到下一步如何据此进行外部设计需要有逻辑思维能力，用最近的话说就是logical thinking。顾客单方面的表达自己的需求，在当场立刻明白那些功能是能实现，哪些是不能实现的是非常重要的。举个极端的例子，开发考勤管理系统。明明没有记录每天的上班下班时间，却要用图表显示每月的工作时间，这样的需求显然是无法实现的。这种情况下，要么提出开发一个新功能记录每天的上班下班时间，要么与顾客讨论是否

7、真的需要算出每个月的工作时间这个功能。外部设计之前，要件定义阶段，发现需求不合理的能力是非常重要的。要件定义开始条件1.侧要求事项整理事。2.开発案件受注、契约缔结事。中文：1.用户整理要求事项。2.发包并签订合约。要件定义目的1.业务化要求作业要求定义。成果物要求定义书。2.要求実现、化要件作业要件定义。成果物要件定义书。3.要件定义、化范囲明确、开発工数费用见积为行。中文：1.整理用户要求的作业为要求定义。成果物是要求定义书。2.整理系统要件的作业为要件定义。成果物为要件定义书。3.要件定义的目的是为了明确系统范围，预估系统开发所需工数及费用。要件定义担当1.要求定义、要件定义中心行。2.

8、侧関系部门担当者集、化委员会発足、要求事项导出、要件定义行。3.开発者情报関専门知识提供、要件定义作业支援。中文：1.要求定义及要件定义应该以用户为中心。2.用户应召集相关部门负责人，成立系统委员会，导出并整理要求事项，进行要件定义。3.开发人员提供信息系统相关的专业知识，支援用户的要件定义作业。要件定义方法1.化事明确定义、开発者漏伝。2.自业务定义。、谁、何、何为记述。3.业务上何问题挙。问题対解决记述。4.解决方法、业务止、运用変、化等、面体制面、関系者影响等、侧面検讨、决定。5.问题解决方法中化、开発者情报専门家立场助言。中文：1.用户须明确定义系统要求，并要无一遗漏的传达给开发人员。

9、2.用户须定义自己的业务。逐一记录谁、在哪里、做什么、怎样做、为什么做。3.列举业务方面存在的问题。记录每一问题如何解决。4.解决方案有“终止业务”、“外包”、“变更应用”、“系统化”等多种，须从成本、体制、对利害关系人的影响等多种层面研究后决定。5.关于解决方法之一的“系统化”，开发人员须以信息系统专家的立场提出谏言。要件定义基资料1.中长期事业计画书。2.业务内部资料（业务/业务定义书/业务等）。3.业务课题一覧。4.现行、现行各种资料（出力帐票/操作/设计书/仕様书等）。5.。6.用纸。7.打合议事録。中文：1.中长期事业计划书。2.业务内部资料（业务指南/业务定义书/业务流等）。3.业

10、务课题一览。4.如有现行系统，则需提供现行系统的各种资料（出力帐票/操作指南/设计书/仕様书等）。5.听取页。6.调查问卷。7.会议记录。要件种类业务面业务部署拠点効率面机能操作性品质性能运用面保守性拡张性安全性运用运用体制要件定义确认1.课题何。2.课题何时続。3.课题何时解决。4.课题解决効果见込。5.课题主部署谁担当。6.课题解决。7.何故、解决方法取。8.课题何原因起。9.课题放置影响。10.课题解决方法、化选。中文：1.课题是什么。2.课题持续到什么时候。3.课题在什么时间前必须解决。4.课题解决后会有怎样的效果。5.课题主要是由哪个部门的谁负责。6.课题准备如何解决。7.为什么采取

11、这种解决办法。8.课题是基于什么原因发生的。9.课题不做处理的话会有怎样的影响。10.课题作为解决办法，没有选择系统化会怎样。要件定义书项目1.项番2.部门3.部门担当者4.业务名5.课题6.课题分类(経営戦略、情报戦略、业务上问题等)7.対応方法8.対応方法分类(业务変更、业务廃止、変更、新规化等)9.実现可能性10.优先度11.実施期限12.备考要件定义书作成时注意点1.一项目一要件书。复数要件书。2.表现统一。中文：1.一个要件自成一项。2.统一采用“”这种表达形式。要件定义変更管理1.必文书事。2.変更理由背景明确事。3.関系者合意取事。4.他要件整合性取事。5.工数费用见积、周知事。

12、6.技术的里付取事。7.优先度実现时期确认事。8.効果试算事。9.変更履歴残事。中文：1.采用书面管理。2.明确变更理由和背景。3.与利害关系人达成一致。4.与其他要件没有矛盾。5.预估工数和费用并让成员周知。6.保留技术证据。7.确认优先级和实现期间。8.试算效果。9.保留变更履历。成果物1.业务定义书2.现行业务3.新业务4.要求事项一覧5.课题一覧6.议事録7.要件定义书终了条件1.要件定义书関、侧开発侧合意取事。中文：1.关于要件定义书，用户和开发人员要达成一致。设计开始条件1.要件定义终了、要件确定事。中文：1.要件定义结束，要件已经确认。概要定义1.目的（期待効果）记述。2.范囲（

13、対象业务対象部署実现机能）记述。3.前提条件（事事実现程度）记述。4.概要（机能概要运用処理概要）记述。中文：1.描述系统目的（期待效果）。2.描述系统范围（对象业务対象部署实现机能）。3.描述系统的前提条件（能做的事不能做的事实现程度）。4.描述系统概要（机能概要运用処理概要）。方式设计1.（PC机种CPU）构成図作成。2.（回线回线速度）构成図作成。3.（名）构成図作成。中文：1.作成硬件（服务器PC打印机机型CPU内存硬盘）构成图。2.作成网络（回线调制解调器路由器集线器桥接器转发器回线速度）构成图。3.作成软件（软件名称版本号）构成图。成果物1.概要定义书2.构成図（构成构成构成）中文：1.系统概要定义书2.系统构成图（硬件构成软件构成网络构成）终了条件1.成果物完成事。2.成果物承认得事。中文：1.成果物完成。2.成果物得到用户认可