对日软件开发作业流程.docx

对日软件开发作业流程.docx

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

对日软件开发作业流程

对日软件开发步骤

日本软件项目开发进度控制很严格，项目极少出现延期，一旦延期，伴随而来就是大宗罚款，所以，日本软件项目很重视按期交付。

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

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

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

要件定义指业务需求具体确定和系统需求具体确定，系统需求关键包含软件安全性，运行速度，网络环境，运行环境，平台，架构等方面要求，和技术选择调查，本阶段出具《业务要件定义书》和《系统要件定义书》。

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

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

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

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

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

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

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

对日开发基础步骤中包含了以上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.结果物得到用户认可