对日软件开发流程.docx

对日软件开发流程.docx

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

对日软件开发流程

对日软件开发流程

日本的软件项目开发进度控制非常严格，项目很少出现延期，一旦延期，伴随而来的就

是大宗的罚款，因此，日本的软件项目非常重视按期交付。

在日本软件项目进度控制中起关

键作用的就是软件的阶段定义。

日本软件项目阶段分项目提案、要件定义、概要设计、详细设计、编写代码、单体测试、

结合测试、系统测试、编写手顺等。

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

要件定义指业务需求的详细确定和系统需求的

详细确定，系统需求主要包括软件安全性，运行速度，网络环境，运行环境，平台，架构等方面的要求，以及技术选择的调查，本阶段出具《业务要件定义书》和《系统要件定义书》概要设计指功能设计，系统架构设计，界面设计和数据库设计，其中界面设计和数据库设计涉及内容最多，要求最详细，本阶段出具《概要设计定义书》、《数据库设计定义书》和《界

面设计定义书》。

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

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

单体测试指由各模

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

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

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

用户数据进行系统测试，本阶段出具《系统测试票》。

编写手顺指编写用户手册，本阶段出

具《安装手顺》、《使用手顺》和《维护手顺》。

对日开发的基本流程中包括了以上11个阶段，每个阶段为一个里程碑，每个里程碑在

安排计划时都规定了明确的完成期限，这些阶段性的里程碑是项目进度的关键点。

每个阶段

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

阶段

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

只采用阶段Review的方式进行验收也有其不足之处，所有验收工作都放在阶段完成再

进行，阶段中的错误后续持续放大无法得到控制。

而且通常情况下，阶段Review时问题会

比较多，Review后修改时间比较长，修改次数也较多，造成很大程度的反复工作。

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

Review时解决。

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

输入

输出

1.顾客的业务需求

1•要件定义书

2.网络结构定义书

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

系统的开发是为了顾客企业的业务更灵

活及高效。

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

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

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

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

要明白为什么必须系统化，为什么要建立

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

这样的商业模型，要收集各方面的需求，不能有遗漏。

因为到后期，当发现需求分析不充分

时将导致整个开发的系统都无用。

另外，如果做了过多的分析，只要将不用的功能放弃掉就

可以，对进度的影响很小。

当然，对不需要功能的开发投入的金钱成本，顾客是不需要支付

的，全部由开发方负责。

2.与顾客谈判的能力

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

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

对方。

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

调好。

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

相当重要的能力。

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

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

顾客单方面的表达自己的需

求，在当场立刻明白那些功能是能实现，哪些是不能实现的是非常重要的。

举个极端的例子，

开发考勤管理系统。

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

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

外部设计之前，要件

定义阶段，发现需求不合理的能力是非常重要的。

要件定義

■開始条件

i.二一廿'側疋要求事項力•整理事。

2.八亍厶開発案件总受注契約力•締結事。

中文：

1.用户整理要求事项。

2.发包并签订合约。

■要件定義①目的

1.業務总》入亍厶化歹召七吉忙二一廿①要求作業总要求定義乩巧。

乞①成

果物总要求定義書^、刁。

2.要求总実現S/X^A化①要件作業总要件定義乞①成果物总要件定義書m、^o

3.要件定義/X亍厶化①範囲总明確^L>/X亍厶開発忙力、力、召工数壬費用总見積

£•5爲V哲行

中文：

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

成果物是要求定义书。

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

成果物为要件定义书。

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

■要件定義①担当

1.要求定義、指要件定義总二一廿中心疋行

2.二一廿側疋関係部門①担当者总集皿、/X亍厶化①委員会总発足^乜、要求事項①

導出、要件定義总行

3.開発者处情報八亍皿関歹召専門知識总提供—二一廿①要件定義作業总支援歹

中文：

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

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

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

■要件定義①方法

1.二一入亍厶化。

尢事总明確忙定義開発者忙漏伝元肚疗料泾肚乙肚

2.二一廿自①業務总定義m、誰力•、乂乙疋何艺

何O爲記述

3.業務上何力•問題挙厅'^Yo^n^no問題忙対

解決歹力、总記述r^o

4.解決方法^怎、任o業務总止?

>?

7^by-^y^r§?

、？

運用总変元召?

»

入亍厶化?

等力卷*口入卜面壬体制面、関係者^o影響等肚側面力、

検討lt、決定r^o

5.問題解決o方法o中力、入亍厶化開発者肚情報S/X^Ao専門

家o立場疋助言LT^

中文：

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

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

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

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

记录每一问题如何解决。

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

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

■要件定義①基資料

1.中長期事業計画書。

2.業務内部資料（業務V二^7^/業務定義書/業務7口一等）。

3.業務課題一覧。

4.現行、現行八亍S各種資料（出力帳票/操作V二二7儿/設計書

/仕様書等）。

5.匕7】丿〃/一卜。

6.7〉^一卜用紙。

7.打弐合初乜議事録。

中文：

1.中长期事业计划书。

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

3.业务课题一览。

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

5.听取页。

6.调查问卷。

■要件①種類

業務面

業務声二一儿?

部署？

拠点？

効率

S/X^A面

機能？

操作性？

品質？

性能？

七丰二】丿亍彳

運用面

UVX?

保守性？

拡張性？

安全性？

運用HX卜?

運用体制？

UX夕?

f儿

XX夕

■要件定義①確認

1.課題处何力、。

2.乞①課題总何時去疋続力、。

3.乞①課題总何時解決

4.乞o課題总解決効果力•見込力、。

5.乞O課題总主gS部署O誰力•担当LT^^O^o

6.乞O課題解決

7.何故、乞肚解決方法总取5O力、。

8.乞O課題总何力•原因疋起乙二尢O力、。

9.乞O課題总放置影響力•笳5O力、。

10.乞O課題总解決方法七LT、》入亍厶化总選力、。

中文：

1.课题是什么。

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

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

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

6.课题准备如何解决。

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

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

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

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

■要件定義書①項目

1.項番

2.部門

3.部門担当者

4.業務名

5.課題

6.課題分類□一F（経営戦略、情報戦略、業務上①問題等）

7.対応方法

8.対応方法分類□一（業務口七入変更、業務廃止、少入亍厶変更、新規化

等）

9.実現可能性

10.優先度

11.実施期限

■要件定義書作成時①注意点

1.一oo項目忙一二①要件总書〈。

複数①要件总書力畑、。

2.「〜总〜歹召肚表現疋統一歹^。

中文：

1.一个要件自成一项。

2.统一采用〜总〜歹召”这种表达形式。

■要件定義o変更管理

1.必于文書事。

2.変更o理由壬背景力•明確疋笳召事。

3.関係者o合意力•取事。

4.他o要件七o整合性力•取事。

5.工数壬費用总見積哲^、周知歹召事。

6.技術的肚裏付疗总取召事。

7.優先度七実現歹召時期总確認歹召事。

8.効果总試算歹召事。

9.変更。

尢履歴总残歹事。

中文：

1.采用书面管理。

2.明确变更理由和背景。

3.与利害关系人达成一致。

4.与其他要件没有矛盾。

5.预估工数和費用并让成员周知。

6.保留技术证据。

7.确认优先级和实现期间。

8.试算效果。

9.保留变更履历。

■成果物

1.業務定義書

2.現行業務7口一

3.新業務7口一

4.要求事項一覧

5.課題一覧

6.議事録

7.要件定義書

■終了条件

1.要件定義書q関疋、二一廿'側上開発側①合意力'取事。

中文：

1.关于要件定义书，用户和开发人员要达成一致。

少入亍L設計

■開始条件

1.要件定義力■終了要件力•確定事。

中文：

1.要件定义结束，要件已经确认。

■少入亍厶概要定義

1.目的（期待歹召効果）总記述

2./X亍厶O範囲（対象O業務？

対象部署？

実現機能）总記述T^o

3./X亍厶O前提条件（疋吉召事？

事？

実現O程度）总記述T^o

4./X亍厶O概要（機能概要？

運用処理概要）总記述T^o

中文：

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

2.描述系统范围（对象业务？

対象部署？

实现机能）。

3.描述系统的前提条件（能做的事？

不能做的事？

实现程度）。

4.描述系统概要（機能概要？

運用処理概要）。

■/X亍厶方式設計

1.八一F片工了（廿一八?

pc?

7°u＞夕？

機種?

cpu?

?

八一F'^Yx夕）構成図总

作成歹

2.木少卜乃一夕（回線？

壬〒'厶?

儿一夕？

八7'、?

?

】丿丄一夕？

回線速度）構成図总作成

3.y7b^x7（V7b^x7名？

）構成図总作成T^o

中文：

1.作成硬件（服务器？

PC?

打印机？

机型？

CPU?

内存？

硬盘）构成图。

2.作成网络（回线？

调制解调器？

路由器？

集线器？

桥接器？

转发器？

回线速度）构成图。

3.作成软件（软件名称？

版本号）构成图。

■成果物

1.概要定義書

2./X亍厶構成図（八一F少工了構成？

V7b^x7構成？

木少卜乃一夕構成）

中文：

1.系统概要定义书

2.系统构成图（硬件构成？

软件构成？

网络构成）

■終了条件

1.成果物力•完成事。

2.成果物力•二一廿^承認总得事。

中文：

1.成果物完成。

2.成果物得到用户认可