对日软件开发流程.docx

对日软件开发流程.docx

《对日软件开发流程.docx》由会员分享，可在线阅读，更多相关《对日软件开发流程.docx（11页珍藏版）》请在冰豆网上搜索。

对日软件开发流程

RevisedbyLiuJingonJanuary12,2021

对日软件开发流程

对日软件开发流程

日本的软件项目开发非常严格，项目很少出现延期，一旦延期，伴随而来的就是大宗的罚款，因此，日本的软件项目非常重视按期交付。

在日本软件项目进度控制中起关键作用的就是软件的阶段定义。

日本软件项目阶段分项目提案、要件定义、概要设计、详细设计、编写代码、单体测试、结合测试、系统测试、编写手顺等。

项目提案指项目可行性分析、项目立项，是用户需求的正式提出阶段，本阶段出具《项目提案书》。

要件定义指业务需求的详细确定和系统需求的详细确定，系统需求主要包括软件性，运行速度，网络环境，运行环境，，架构等方面的要求，以及技术选择的调查，本阶段出具《业务要件定义书》和《系统要件定义书》。

概要设计指功能设计，系统架构设计，界面设计和数据库设计，其中界面设计和数据库设计涉及内容最多，要求最详细，本阶段出具《概要设计定义书》、《数据库设计定义书》和《界面设计定义书》。

详细设计主要指编码前的类设计，类中方法属性设计，类之间调用关系设计，本阶段出具《详细设计定义书》。

编写代码指各模块负责人编写相关代码，在编码之前还要编写单体测试式样书，本阶段出具程序源码和《单体测试式样书》。

单体测试指由各模块编码人员完成各自模块的单体测试工作，单体测试完成要求各模块独立运行时缺陷均消除，本阶段出具《单体测试票》。

结合测试指各模块单体测试完成后，各模块同时运行时，模块之间的运行状况的测试，包括业务流，负载，运行速度，稳定性，一致性等内容，本阶段出具《结合测试票》。

系统测试指系统各模块统一运行缺陷均消除后，模拟用户环境运行的测试过程，本阶段要尽量模拟用户实际平台，用户数量，硬件环境，软件环境，网络状况，用户数据进行系统测试，本阶段出具《系统测试票》。

编写手顺指编写用户手册，本阶段出具《安装手顺》、《使用手顺》和《维护手顺》。

对日开发的基本流程中包括了以上11个阶段，每个阶段为一个里程碑，每个里程碑在安排计划时都规定了明确的完成期限，这些阶段性的里程碑是项目进度的关键点。

每个阶段完成后必须进行阶段的Review，这种阶段Review起到了阶段验收和总结的作用。

阶段Review是日本项目阶段控制的核心。

只采用阶段Review的方式进行验收也有其不足之处，所有验收工作都放在阶段完成再进行，阶段中的错误后续持续放大无法得到控制。

而且通常情况下，阶段Review时问题会比较多，Review后修改时间比较长，修改次数也较多，造成很大程度的反复工作。

再有，对日软件开发过程中，阶段内任务的安排和验收比较；无序，很多问题会被有意推迟到Review时解决。

要件定义决定了系统全部的功能，说本阶段产出的成果物左右了整个系统的成败也不为过。

输入

输出

1.顾客的业务需求

1.要件定义书

2.网络结构定义书

要件定义的输入是顾客想要系统化的业务需求。

系统的开发是为了顾客企业的业务更灵活及高效。

而要件定义的目的就是明确顾客想要系统化的业务逻辑。

进行要件定义所需具备的能力

当进行上面所说的要件定义时，需要有以下的能力。

1.理解顾客企业的商业模型

必须要充分理解顾客是如何进行商业活动的。

要明白为什么必须系统化，为什么要建立这样的商业模型，要收集各方面的需求，不能有遗漏。

因为到后期，当发现需求分析不充分时将导致整个开发的系统都无用。

另外，如果做了过多的分析，只要将不用的功能放弃掉就可以，对进度的影响很小。

当然，对不需要功能的开发投入的金钱成本，顾客是不需要支付的，全部由开发方负责。

2.与顾客谈判的能力

与人谈判的能力是指待人能力，协调能力。

对方是给钱的顾客，不能用严厉的语言激怒对方。

对于无法理解的需求要努力在当时就理解了，对于顾客所要求的不合理的需求要能协调好。

这个不像其它的能力可以通过培训或以往的经验来弥补，主要取决于个人的性格，是相当重要的能力。

3.进行要件定义的同时，要能想象到下一步如何据此进行外部设计

需要有逻辑思维能力，用最近的话说就是logicalthinking。

顾客单方面的表达自己的需求，在当场立刻明白那些功能是能实现，哪些是不能实现的是非常重要的。

举个极端的例子，开发考勤管理系统。

明明没有记录每天的上班下班时间，却要用图表显示每月的工作时间，这样的需求显然是无法实现的。

这种情况下，要么提出开发一个新功能记录每天的上班下班时间，要么与顾客讨论是否真的需要算出每个月的工作时间这个功能。

外部设计之前，要件定义阶段，发现需求不合理的能力是非常重要的。

要件定义

■开始条件

1.ユーザ侧で要求事项が整理されている事。

2.システム开発案件を受注し、契约が缔结されている事。

中文：

1.用户整理要求事项。

2.发包并签订合约。

■要件定义の目的

1.业务をシステム化するときにユーザの要求をまとめる作业を要求定义という。

その成果物を要求定义书という。

2.要求を実现するために、システム化の要件をまとめる作业を要件定义という。

その成果物を要件定义书という。

3.要件定义は、システム化の范囲を明确にし、システム开発にかかる工数や费用を见积もる为にも行う。

中文：

1.整理用户要求的作业为要求定义。

成果物是要求定义书。

2.整理系统要件的作业为要件定义。

成果物为要件定义书。

3.要件定义的目的是为了明确系统范围，预估系统开发所需工数及费用。

■要件定义の担当

1.要求定义、および要件定义はユーザ中心で行うべきである。

2.ユーザ侧で関系部门の担当者を集めて、システム化の委员会を発足させ、要求事项の导出やとりまとめ、要件定义を行う。

3.开発者は情报システムに関する専门知识を提供し、ユーザの要件定义作业を支援する。

中文：

1.要求定义及要件定义应该以用户为中心。

2.用户应召集相关部门负责人，成立系统委员会，导出并整理要求事项，进行要件定义。

3.开发人员提供信息系统相关的专业知识，支援用户的要件定义作业。

■要件定义の方法

1.ユーザはシステム化したい事を明确に定义し、开発者に漏れなく伝えなければならない。

2.ユーザは自らの业务を定义しなければならない。

いつ、谁が、どこで何を、どのようにしているのか、何の为にそれをしているのかをひとつずつ记述しなければならない。

3.业务上何が问题になっているのかを挙げていく。

それぞれの问题に対してどのように解决するのかを记述する。

4.解决方法には、その业务を止める、アウトソーシングする、运用を変える、システム化する等があり、コスト面や体制面、関系者への影响等、いろいろな侧面から検讨して、决定する。

5.问题解决の方法の中からシステム化するものについて、开発者は情报システムの専门家の立场で助言していく。

中文：

1.用户须明确定义系统要求，并要无一遗漏的传达给开发人员。

2.用户须定义自己的业务。

逐一记录谁、在哪里、做什么、怎样做、为什么做。

3.列举业务方面存在的问题。

记录每一问题如何解决。

4.解决方案有“终止业务”、“外包”、“变更应用”、“系统化”等多种，须从成本、体制、对利害关系人的影响等多种层面研究后决定。

5.关于解决方法之一的“系统化”，开发人员须以信息系统专家的立场提出谏言。

■要件定义の基になる资料

1.中长期事业计画书。

2.业务内部资料（业务マニュアル/业务定义书/业务フロー等）。

3.业务课题一覧。

4.现行システムがあれば、现行システムの各种资料（出力帐票/操作マニュアル/设计书/仕様书等）。

5.ヒアリングシート。

6.アンケート用纸。

7.打ち合わせ议事録。

中文：

1.中长期事业计划书。

2.业务内部资料（业务指南/业务定义书/业务流等）。

3.业务课题一览。

4.如有现行系统，则需提供现行系统的各种资料（出力帐票/操作指南/设计书/仕様书等）。

5.听取页。

6.调查问卷。

7.会议记录。

■要件の种类

业务面

业务スケジュール部署拠点効率

システム面

机能操作性品质性能セキュリティ

运用面

リソース保守性拡张性安全性运用コスト运用体制リスクヘルプデスク

■要件定义の确认

1.课题は何か。

2.その课题は何时まで続くのか。

3.その课题は何时までに解决しなければならないのか。

4.その课题を解决するとどのような効果が见込めるか。

5.その课题は主にどこの部署の谁が担当しているのか。

6.その课题はどのように解决しようとしているのか。

7.何故、そのような解决方法を取るのか。

8.その课题は何が原因で起こったのか。

9.その课题を放置するとどのような影响があるのか。

10.その课题を解决する方法として、システム化を选ばなかったらどうなるか。

中文：

1.课题是什么。

2.课题持续到什么时候。

3.课题在什么时间前必须解决。

4.课题解决后会有怎样的效果。

5.课题主要是由哪个部门的谁负责。

6.课题准备如何解决。

7.为什么采取这种解决办法。

8.课题是基于什么原因发生的。

9.课题不做处理的话会有怎样的影响。

10.课题作为解决办法，没有选择系统化会怎样。

■要件定义书の项目

1.项番

2.部门

3.部门担当者

4.业务名

5.课题

6.课题分类コード（経営戦略、情报戦略、业务上の问题等）

7.対応方法

8.対応方法分类コード（业务プロセス変更、业务廃止、システム変更、新规システム化等）

9.実现可能性

10.优先度

11.実施期限

12.备考

■要件定义书作成时の注意点

1.一つの项目に一つの要件を书く。

复数の要件を书かない。

2.「～を～する」のような表现で统一する。

中文：

1.一个要件自成一项。

2.统一采用“～を～する”这种表达形式。

■要件定义の変更管理

1.必ず文书にする事。

2.変更の理由や背景が明确である事。

3.関系者の合意が取れている事。

4.他の要件との整合性が取れている事。

5.工数や费用を见积もり、周知する事。

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.システムの范囲（対象の业务対象部署実现する机能）を记述する。

3.システムの前提条件（できる事できない事実现の程度）を记述する。

4.システムの概要（机能概要运用処理概要）を记述する。

中文：

1.描述系统目的（期待效果）。

2.描述系统范围（对象业务対象部署实现机能）。

3.描述系统的前提条件（能做的事不能做的事实现程度）。

4.描述系统概要（机能概要运用処理概要）。

■システム方式设计

1.ハードウェア（サーバPCプリンタ机种CPUメモリハードディスク）构成図を作成する。

2.ネットワーク（回线モデムルータハブブリッジリピータ回线速度）构成図を作成する。

3.ソフトウェア（ソフトウェア名バージョン）构成図を作成する。

中文：

1.作成硬件（服务器PC打印机机型CPU内存硬盘）构成图。

2.作成网络（回线调制解调器路由器集线器桥接器转发器回线速度）构成图。

3.作成软件（软件名称版本号）构成图。

■成果物

1.システム概要定义书

2.システム构成図（ハードウェア构成ソフトウェア构成ネットワーク构成）

中文：

1.系统概要定义书

2.系统构成图（硬件构成软件构成网络构成）

■终了条件

1.成果物が完成している事。

2.成果物がユーザの承认を得ている事。

中文：

1.成果物完成。

2.成果物得到用户认可