日本编写软件的流程.docx

日本编写软件的流程.docx

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

日本编写软件的流程

日本编写软件的流程

分类:

默认栏目

2006.12.1820:

55作者：

nahelei|评论：

0|阅读：

388

日本一向以品质严格出名。

日本专案不仅脚踏实地，还可以秉持自己的原则、利用企业文化的方式，创造出最有效率的专案开发手法。

且不管其他国家如何追随欧美的脚步，赶着CMMI的潮流，日本依然坚持自己的品管方式，不需要CMMI背书，世界各地的客户依然可以信任日本的产出品质，他们到底是如何做到的？

凡致力於软体品质的工程师不难发现，维护品质最重要的因素就是成本，因为品质=成本。

那麽如何有效运用成本达到最高品质管理应该就是我们必须克服的最大议题。

目前我们所知有效降低成本的最好方式就是资源再利用，每一次的资源再利用应该都可以节省三成以上的成本。

因此，找寻最佳专案进行方式後转换成专案经验并建立为企业文化则是刻不容缓的任务。

有效的资源再利用并不只是相信单单在技术方面拥有物件导向的观念、技术就可以完全有效缩减成本，或是达到资源再利用的任务。

前端系统分析的产业知识亦是真正资源再利用的精华所在。

了解的专案越多我们越可以发现，专案多余成本的分布几乎都集中後期的翻修成本上（如图1专案成本分布图所示）。

图1专案成本分布图

TOP

需求沟通

翻修成本的产生不外乎是发生在使用者需求变更、系统设计变更上。

而一般而言，会发生变更的环节大致上是在使用流程改变、使用者与系统分析师沟通不良、系统设计师与程式设计师沟通不良等问题上。

沟通除了面谈、会议的面对面沟通以外还有文件上的沟通亦甚为重要，整个系统开发沟通过程与我们从小到大的教学过程很类似（如图2系统开发沟通示意图）。

面谈就好像是老师上课，交付需求结果整理文件就好像是学生交功课一样。

把面谈的结果（老师上课的内容）转换成交付文件的内容（学生交功课），但若排除技术因素，学生交的功课如果连老师都看不懂，那麽老师又该如何告知学生哪里与他上课的内容（要求的功能）有差异呢？

所以只能等到考试当天（系统测试），才发现学生的成绩有够差，答非所问，只好不停的重新上课（从技术人员的角度来看，就视为需求变更）然後要求学生不停的补考（规格变更，程式必须修改），自然就会造成专案成本的浪费。

图2系统开发沟通示意图

排除专案本身无法控制的使用流程变更外，使用者与系统分析师沟通不良、系统设计师与程式设计师沟通不良等问题应该都是可以利用工具及资料库统一管理的方式来克服。

使用者若有与系统分析师沟通不良的问题存在，应表示系统分析师使用太多的系统语言表达需求访谈的结果，而非利用使用者语言表达需求访谈的结果。

原来使用者对电脑这类「高科技」产物都会存有一定的排斥感，觉得那是不同世界的东西，要他确认怎麽可能？

甚至部份极端心态会认为如果自己真的「懂」的话，不就自己开发系统就好了吗？

正因为存在着先入为主的排斥感，如果我们还拿着辛苦熬夜画出来的「系统流程图」（图3、5系统流程图）而非「业务流程图」（图4、6业务流程图）让使用者确认的话，相信这份文件应该很难获得使用者签章的。

要获得使用着的认可，一定要先站在使用着的角度了解他们的业务流程，并将其业务流程文件化後才从中萃取电脑系统所需的资讯。

千万不可只看自己想看的部份，片面认为其他与电脑无关的流程都不重要。

要累积产业知识其实也都必须清楚了解使用者端的业务流程，日後才有办法提出系统流程改善的建议，也可以从系统分析进一步进入顾问的角色。

图3系统流程图（例1）

图4业务流程图（例1）

图5系统流程图（例2）

图6业务流程图（例2）

TOP

但若规格变更经常发生在系统设计师与程式设计师沟通不良的问题上，则必须反省系统分析阶段的文件化过程是否标准化？

系统分析文件内容是否详尽？

分析结果文件是否即时反应客户需求？

要具体解决这个问题，正确使用系统分析工具是唯一解决途径。

只要全公司使用整合资料库管理系统分析结果，不仅可以达到即时掌握客户需求的效果，更可以确保系统分析作业过程标准化，产出文件统一化。

藉此可以避免各系统分析师描述习惯不同导致实际开发人员无所适从，或是无法正确掌握系统分析师语意之情况发生。

加上目前转档技术已相当发达，很多致力於标准化的软体公司甚至都自行开发转档介面（Bridge）将前端系统分析结果透过程式移转至後端开发工具，更进一步节省重复开发人力（前端分析结果的ERModel或GUI操作介面至开发环境不须重复输入）。

日本企业亦相当重视如何利用工具（CASETool）有效提升使用者与系统分析师沟通不良、系统设计师与程式设计师沟通不良的根本问题（如图7专案工具使用所示）。

图7专案工具使用

TOP

案例一:

JM&C公司

举几个日本大型企业为例，软体专案开发工程从前端系统分析至系统完成、上线测试几乎都有支援工具协助开发。

且目前皆是利用工具资料库的观念将前端分析资料不停的往下一个阶段抛转，以其达到即时资料更新的目的并杜绝前後端资料不一致的根本问题。

例如：

（JAPANENERGYCORPORATION）（如图8）遵循TCSM（TheClientServerMethodology）方法论（由JM&C公司所提倡之C/S型BusinessApplication开发方法论）之精神，将系统分析阶段的资料转入资料库设计工具後，再利用程式开发工具进行系统开发。

而（JAPANENERGYCORPORATION）发扬TCSM的精神为「前端分析要仔细、後端开发要快速」并视为软体专案开发之执行重点。

图8（JAPANENERGYCORPORATION）工具应用实例

TOP

案例二:

三菱商事

三菱商事（MITSUBISHICORPORATION）（如图9）则是以制定公司内部系统开发标准规约之「系统开发实务基准」为目的，利用复数开发工具与套装软体串接使用，藉以提高开发生产力，并规定於开发层面必须遵守DOA、Prototyping、RAD等使用者可积极参与之系统开发方式。

且因三菱商事之软体开发工程约有80%为委外开发，因此如何将作好知识管理，将产业知识传承於公司内部并可与外包商有良好互动，亦是三菱商事整合制定「系统开发实务基准」时之重大考量。

图9三菱商事（MITSUBISHICORPORATION）工具应用实例

TOP

案例三:

东海ＮＴＴ

东海ＮＴＴ通信（NTTDATATOKAICORPORATION）（如图10）为了满足1.克服大规模专案（细部设计结束前平均40位、最多时70位开发人员同时作业）开发、2.因契约形态不同，业务组合已脱离既有「人、物、金」观念，较为繁杂、3.旧系统程式依附程式设计师之个人技术程度，新系统应排除个人属性将品质统一化、4.参与专案开发子公司众多，必须统一开发手法与技术、5.除了必须适用总公司之制度变更，并需可弹性应对大规模与紧急规格变更、6.设计资讯一元化，随时可取得最新规格书、7.不被环境左右之应用系统，AS/400平台之旧系统评价相当高，新系统亦被要求相同品质之种种要求，锁定应用前端系统分析工具管理专案开发工程，更善加利用前端系统分析工具与後端开发工具之资料抛转功能，成功开发历时3年、DBMS为Oracle8、使用终端机6000～7000台、横跨4间公司之大型专案。

图10东海ＮＴＴ通信（NTTDATATOKAICORPORATION）工具应用实例

TOP

案例四:

日立情报

日立情报（HitachiInformationSystems,Ltd.）（如图11）因与客户沟通不良，经常发生规格确认延迟等问题。

且因前端分析工程较依存人的运用，常会因设计者经验不足而导致不可避免的循环修改成本浪费。

故为解除与客户间之沟通差异（GAP）、减少设计缺陷并降低设计矛盾点、提升知识能力并确实累积公司经验，日立情报不仅导入前端系统分析工具，更自行开发与後端程式开发工具-VB（VisualBasic）之资料移转介面。

不仅可以将前端分析工具之GUI操作介面透过程式自动移转至後端程式开发工具，更可以利用後端程式开发工具自动产生VB程式码，朝自动化软体工程更加迈出一大步。

图11日立情报（HitachiInformationSystems,Ltd.）工具应用实例

参考上述几个日本大型企业之软体专案开发手法後，我们可以得知人工开发手法已无法满足各种大型专案之需求，过去小型专案虽不讲究程序标准化，但随着软体专案规模逐渐扩大，软体专案开发工程如何建立标准、文件如何规格化、产业知识如何累积都是各大企业开始注意的重要议题。

相信有程序及经过标准化的工具开发手法一旦成为企业文化，即使不需要CMMI的背书，有制度的专案品质亦可以得到客户的信赖。

TOP

作者简介

冯文郁

学历：

日本中央大学商学部毕业

经历：

曾多次参与日本／台湾、台湾／大陆共同开发之软体专案、92年9月取得软体品质工程师资格认证。

你可以通过这个链接引用该篇文章:

精心整理，仅供参考编辑文案使用，请按实际需求再行修改编辑

2020年2月17日

精心整理，仅供参考编辑文案使用，请按实际需求再行修改编辑

2020年2月17日