Rapid Software Development can revolutionize corporate systems - an epoch-making innovation of software making -	Cat: ICT Pub: 2014 #: 1411b
	ICT Management Partners Association (ICT経営パートナーズ協会)	14702u/18208r

Title Rapid Software Development can revolutionize corporate systems 超高速開発が企業システムに革命を起こす Index Rapid SW development is urged: Advantage of Rapid SW development method: Practices of Evolving Prototype Development: Problem & Impact of Rapid SW Development: Cases of Rapid SW development: Rapid SW development Tool List: 企業経営から見た超高速開発への期待: 超高速開発の優れている点: 進化型プロトタイプ開発の実践: 超高速開発活用の課題と対策: 超高速開発の活用事例: 超高速開発ツールリスト: Tag Abstraction level; Agile manifesto; Agile or Rapid; Asis & Tobe models; Business analysis; Business know-how; Business management system; Case study; Change of communication; Communication skill; Continuous improvement; Cost comparison; Data architecture; Data-centric; Data scientist; Decision making; Different SW development; Easy prototype; End user; Estimate level; Evolutionary prototype; Evolving prototype; Exception & Error handling; Fit & Gap analysis; From V to P; GUI design; How to use tool; HRD; I derived from T; Impact analysis; Indirect jobs; Integrated test; Key success factor; Management accounting; Organizational structure; Previous design; Problems of Rapid; Progress report; Program generation; Project perspective; Proven pattern; Quality management; Quality verification; Ratio of man-power; Reliable document; Relative ratio; Repository; Repository-centric; RFP; Screen design; Simplified WF; Small start; Structure of BP; Transfer from conventional; Subcontractor; UML; Unite test; User's viewpoint; Work Flow chart; XRad; Why The term of 'Rapid SW development' appeared as a special article in the journal of Nikkei Computer in Mar. 2012. Agility matters, but it is not the only purpose of SW development. The theme of this book covers not only agility of SW development, but also considers the present situation and environment surrounding corporations; and challenges to questions why top of corporate management feel unsatisfactory about the most of IT systems? This book was supervised by T. Seki, representative of ICTMP, and co-authored by M. Homma, M. Ohshima, et al, including myself. The launch party was held on 4 June, 2014 having more than 130 guests, drawing interests from the industry. 超高速開発ソフトウェア開発は、2012年3月に日経コンピュータで特集された。 超高速開発は重要だが、ソフト開発の唯一目的ではない。 本書のテーマはソフト開発の高速性だけでなく、企業の現状や環境も視野に入れて、なぜ企業トップが多くがITシステムに満足していないのかの疑問に答えている。 本書は関隆明(ICT経営パートナーズ協会会長)が監修、本間峰一・大島正善他、筆者も含め共著者として参加した。 本書の出版記念パーティーは2014.6.4に関係者130名以上が参加して行われ、業界の関心を呼びつつある。

Résumé	Remarks
>Top 1 Rapid software development is urged Inconvenient situation of present IT systems: Patched up SW, which needs much maintenance cost. No single engineer who understands total IT system. Enormous development or amending cost of add-on of FRP. There are lots of claims of internal end-users about IT system. Too much dependance on the SI vendor, even in the case of minor expansion of SW. No single staff who understands the detailed business rules and RFT of the IT system. Systems eparately developed systems keep similar or redundant files, which may be the cause of troubles. Application SW's supporting smart phone & tablet are urged. None of engineers thinks the present way of SW development is satisfactory. Too much job integrity is required in SW development and for its maintenance. IT related jobs are regarded as labor-intensive, which are unpopular among newcomers. Causes of the inconvenience: Business culture of SI Vendor; labor- intensive based on man-month payment. Too much customization of world famous package SW (like SAP) Too many inconsistent documentation Vendor lock-in; even Users cannot understand their own business analysis and estimae know-how. >Top Documentation of business process (rules): End User should know and make document of the whole business flow of related organization and partners. Valid business rules exist in the code; particularly in the executable files. When neede, reverse engineering tool is used to visualize the program. Abstraction level is different between business rule and program Business rule and Program have not one-to-one correspondence. Cf: Abstraction layer; Data structure Program bugs are used to be found sometimes later in the practice. New rules are well programmed, but old (incumbent) rules are not. Estimate of programs: Tough a certain program was analyzed, the cluster of programs should be estimated. This situatin is totally different from manufacturing process; because none can clarify how many and where the parts are used in SW programming. In manufacturing BOM is Bill of Materials, but in SW engineering, BOM will be Bulk of Materials? Science is usually invisible but precise; SW Engineering is neither visualized (invisible) nor precise (structural control) Customization of Package SW: This trend relates Japanese unique business culture, like unnecessary differentiation or artistic appetite. Change of expectation for IT System: The age of manual jobs, the development SW itself was the target of IT System. But after completion of major IT Systems, usefulness became the target. >Top SW Life Cycle (ISO12207) → System Life Cycle (ISO15288): Manufacturing process is: R&D→Manufacture→Sales and Product Improvement SW Development process is: Design→RFP→Development/Test→Operation .... Continuous Improvement matters. Waterfall Development contradicts the concept of 'Continuous Improvement'; it flow away and never returns. 100% Subcontracting, i.e., Dumping everything on others is inconceivable. Improvement the system through operation. (Iteration) Maintenance phase should be Operation & Improvement phase (DevOps) Structure of Business Model and IT System Structure of Business Model: Client, Sales Lead Product, Services Partner, Supply Chain Purchase, Supply Mechanism Organization, Job Function, Skill Location, Office, Shop Business Process and Business Rule Corporate Motto, Corporate Strategy External and Internal Information Marketing Activity Structure of IT System: M entities correspond to N entities M products are made of N parts M products are handled by N organizations M marketing strategies are promoted by N marketing channels All these M:N relations are mapped multi dimensional list. Business managers and expert operates these relationships almost by intuition. Reduce M:N relations into 1:N is important (Normalization) Commercial transaction flow (Title transfer/Security), Logistics (Delivery/Demurrage), Money (Debt/Credit/Payment) flow, Information flow (Irrevocable/Revocable) Electronic Contract (Delivery base) Conventional Contracts (Dispatch base) BPM (Business Process Management): >Top EA (Enterprise Architecture) Business Architecture (BA): Goal, Requirement, Process, Information, Organization Data Architecture (DA): Entity, Data Item Business Activity is to flow data/information to the latter process, completing PDCA cycle. To visualize the relation of BA and AA is essential. This visualization should be clarified by User who knows the details of Business flow. Application Architecture (AA): Functional requirement, Sub-system, Tier/Layer, Screen, Form Design, Interface Technology Architecture (TA): Design, HW, SW, NW Elements of Design: Design level function Transaction flow User Interface (UI) Data items Database, File Program, Parts, Resources Message Architecture Physical Devices (HW, NW, Devices) >Top Classification of Rapid SW Development Tools: <Chart-1> Type Feature Remarks Type-1 having Repository, just like BOM in manufacturing Repository functions to keep information of business process, and design of SW as metadata. Tools with execution engine (BPMS/BRMS) usually have this function. Some execution tool for testing, batch transaction, or EAI also have such function Type-2 Development using framework or template These tools develop application using framework, transaction patters, parts, and sample applications. Patterning of SW design enables rapid development. Tools for designing UI usually haven't repository. BRMS: Business Rules Management System EAI: Enterprise Application Integration Manufacturing always pursue high quality, high productivity as well as traceability. Such as Aggregation of System Structure Chart, Relationship Diagram of Functions, or RFP are partial documents, which cannot function as a BOM. All the documents are rare to be updated during the period of life cycle. Even aggregated documents are almost useless for maintains. >Top Change of business environment: Change-1: Big data: enormous data are getting available in the network society; a new type of data analyst called Data Scientist is required Data Scientist: a specialist who can generalize knowledge from big data, using economics, statistics, mathematics, pattern recognition, and uncertainty modeling, etc.; Hacking Skill + Math & Statistics knowledge + Substantive Expertise Change-2: Agility: Change of environment is getting more accelerated. Old IT Systems are rapidly obsoleted. >Top Structure of Business Process: Clarify Business Process (BP) Layer structure of BP (Lower Layer job is called Activity or Task) BP indicates PDCA cycle of the organization Transfer of Data between organization (Visualization) Evaluation Criteria; Business Rules Any member is accessible to BP and Business Rules. Response to changes of business environment; Learning organization Human & tools for the changes Contingency plan; Emergency plan Impact of Web System: Business-to -Consumer (B2C): Marketing , Sales, Procurement, Recruitment Business-to-Business (B2B): Marketing, Sales, Procurement Empowered sales person by using Web System	1. 企業経営から見た超高速開発への期待 ITシステムの不都合な現状: システムズ維持コスト膨大 全ITシステム理解者不在 ERP維持費用大 エンドユーザの不満 SIベンダ依存 業務プロセスとRFP データ一元管理 スマホへの対応 IT技術者の疑念 専門家の蛸壺化 ３K職場 その原因 人月ベースの単金 過剰なカスタマイズ バラバラな文書化 ベンダーロックイン ユーザの主体性 文書化: 抽象度(Astract level or layer)の違い Physical level (抽象度大) Logical level: what relationship exist among data. View level (抽象度小） ビジネスルールとプログラム パッケージSWのカスタマイズ ITシステムへの期待 手作業主の時代 QCDでの開発重視 ほぼシステム化が完了 経営への貢献を重視 ユーザの主体性期待 SW開発と製造との違い 継続的改善が重要 ウォーターフォールにはこれがない。 保守フェーズは、運用＆改善フェーズとすべき BOMの有無 ビジネスモデルの構造 顧客・見込客 商品サービス 取引先 購買・販売の仕組み 組織、役割、スキル 立地 (事務所、工場、店舗) ビジネスプロセス 経営理念 マーケティング活動 ITシステムの構造 EAの体系： 業務体系(BA) データ体系(DA) アプリ体系(AA) 技術体系(TA) システム設計の要素 設計レベルの機能 処理の流れ UI データ項目 DB、ファイル プログラム、部品、リソース メッセージ アーキテクチャ 物理装置 (HW, SW, Device) <表１>超高速開発の分類」 Repositoryの有無で Type1とType2がある。 ビジネス環境の変化 ビックデータ 経営の迅速性 データ・サイエンティストという職種 ビジネスプロセスの構造 BPの明確化 BPのLayer 組織全体のPDCA プロセス間情報伝達 ビジネスルール 可視化情報へのアクセツ 変化への対応 変更ツールと人 突発的事象への対応 Webシステムと企業活動 B2C B2B リポジトリ
>Top Differenc of Agile SW Development and Rapid SW Development: （いわゆるアジャイル開発と超高速開発の違い） Features Agile SW Development Rapid SW Development What is Agile/Rapid Agile development of working SW; Agile (=Rapid) Development using Agile methodology Rapid visualization of System Life Cycle; includes shorter period of development, less man-hour development, less rework/return; Ultra-Rapid (=Agile) development using Ultra-Rapid tool Development Initiative User Initiative Vendor Collaborated with User Value Rapid Delivery Consistency with corporate strategy Changing requirements Welcome, even late in development Acceptable, better in earlier change Working SW Delivered frequently Delivered rapidly Size of development team Small (3 -5 ) SWAT (Skilled With Advanced Tools) team, having daily & close communication Size doesn't matter; Smaller expert team is efficient subject to the scale of project Authorization & Motivation Locally started by motivated people Authorized by top management; started from urgent project Co-location Must Preferable, but not necessary Face-to-Face communication Best form of communication Important, also keep document concurrently Measure of progress Working SW Working SW & Document & Performance Frequency of Iterations Usually 3 - 6 months, maintaining a constant pace According to the necessity of improvement Continuous attention to Technical excellence and good design How fullfil the corporate strategy Usage of Tools Yes Yes Simplicity Essential Important from visualization Adaptation to changing environment Regular adaptation to changing circumstances Frequent adaptation to changing circumstances Data model Not necessary mentioned Concept to depository is essential (like BOM) Maintenance Not considered Considered; Maintenance matters. Original concept User initiative, getting outsourced experts on consignment (suited to US style) Vendor/User collaboration; Design & Operation by User initiative; Development by Vendor initiative (suited to Japanese style)
>Top 2. Advantages of Rapid SW Development: Impact of using Rapid SW Development Tool: Thee factors are affected by using the tool: 1) Engineering, 2) Project Management, 3) Skills; Impact to Engineering; <Chart-2-1> # What is affected? Repository type Framework & Template type a Repository-centric jobs ◎   b No need of learning notation (UML, etc.) ◎ ◎ c Easy quality verification ◎   d Easy impact analysis ◎   e Automatic program generations from design information of the repository ◎   f No need of unit test ◎ ◎ g Automatic integrated test ◎   h Reliable documents ◎   i System based on proven patterns   ◎ j Easy making of prototype   ◎ k Change of SW development process ◎ ◎ l Small start then make bigger ◎   Impact to Project Management; <Chart-2-2> # What is affected? Repository type Framework & Template type a Change of method of Quality Management ◎ ◎ b Change of organizational structure ◎   c Change of communication ◎   d Visualization of project perspective ◎ ◎ e More exact progress report ◎   f More rapid decision making ◎ ◎ g Decrease of indirect jobs ◎ ◎ h Change of estimate level ◎ ◎ Impact to Skills; <Chart-2-3> # What is affected? Repository type Framework & Template type a No need of programming and design know-how ◎ △ b More importance of skill of business analysis ◎ ◎ c Idea of data-centric ◎   d No need of learning previous design method ◎ ◎ e More importance of communication skill ◎ ◎ f Need of how to use the tool ◎ ◎ >Top Repository-centric works: Analysis and design works are focussed to register all information to the repository. Development is to make the Standard Output generated from the tool, i.e., standardization is given from the tool; thus there will be no need to decide the standard of output according to each project, which usually takes longer time. Skillful programmers may feel loss of opportunity to show their expertise. There is no need of designing for program development; only need of designing of definition of data, conversion of data, and how to display the output; thus needs more knowledge of business data transaction than that of design of computer system. Repository maintains the relationship between data items, function, screen display, DB, rules. (Data-centric), as unlike as chalk and cheese in documents made by Excel, etc. Once usual business person acquires basic usage, who can develop IT system. >Top No need of UML Notation: UML = Unified Modeling Language; which are needed to develop by object-oriented language like Java or C#. No need of UML, because logical and consistent specification can be made by business analysis.; Standardized design is obtained only by imputing as per the tool prompts, without making Class diagram or Sequence Diagram by UML. >Top Easy Quality Verification: Repository guarantees a certain level of quality such as 1) integrity, 2) uniformity, 3) easiness of understanding, 4) traceability, except 5) comprehension of functions. Conventional large-scale IT development requires the following indirect jobs: review of enormous documents list of findings or insufficiency countermeasures to questions Evaluation Report Integrity Check by Repository (Sample): <Chart-2-4> # What is affected? 1 Function, Screen, DB used in the data items (having unique name) 2 Check of CRUD (appropriateness or omission of function) 3 Confirmation of system function used business process (Easy verification of business transaction) 4 Function of each data item CRUD = basic function of DBMS; Create, Read, Update, and Delete Project progress can be confirmed not weekly but daily. Management for managements will be needless. >Top Easy Impact Analysis: If information registered in the repository is changed, the extent of influence must be confirmed; where the changed data are used in other transaction, screen, or report form as well as CRUD of the DB. (Some DB has R, but hasn't C/U/D. Conventional large-scale IT development, if such changes occur, the extent of influence are checked one by by by each SE-in-charge. Any business change can result in changes of data, data process, or data function. If it is specified, any huge system can be traceable and evaluated the extent of influence. >Top Automatic program generation from the repository: Automatic program of Java, Ruby, C++, RPG (Report Program Generator for AS/400), or COBOL otherwise, CIL (Common Intermediate Language) is generated and stored in the repository; then execution engine works interpreting the CIL. >Top No need of unit test: Unit test usually done for debugging; but automatic program generation need not debugging. But confirmation of design specification is needed. >Top Automatic integrated test: Some repository controls the specification of integrated test, test scenario, ore test case; then test execution engine interpret information stored in the repository and executed automatically the integrated test. Situation of test is visible and can be verified its comprehensiveness and sureness by Quality Control Manager. >Top Reliable documents: Synchronization of program and document matters. Usually as, Code review > Number of programs > Number of functions of each design; code review need lots of man-hour works. As long as design specification synchronizes program code, review can concentrate on review of design specification. >Top System based on proven patterns: The tools without repository have various parts, semi-finished product, or templates which are proven to be high grade and useful: These patterned process can keep high productivity and good quality of development. Some tools provide wide-range of online parts available to users, including not only UI development tools but also business logic. >Top Easy making of prototype: Prototype is made to be confirmed its quality (operability and functions) by the user. >Top Change of different SW development: Kinds of jobs described in WBS (Work Breakdown Structure) is the basic factor to determine SW development process. There are several SW development models, such as 1) Waterfall model, 2) Spiral model, 3) Incremental model, and recently adding 5) Agile development model, 6) DevOps. SW development models have no direct relation to the specific rapid development tool. Herein, we focus DevOps type of rapid development model; which contribute not only rapid SW development but also the SW operation phase. It can affect to design phase of the SW, having visual image of utilization of the new business flow; effective in considering priority of functions which relate investment for SW development.. (Cost per performance) >Top Small start then make bigger: The tool having repository can confirm integrity among factors (including those added later); this function enables to continue SW development without finalizing strict RPF at the earlier stage: This function differs from design tool which only illustrates design chart. This function enables Small start of SW development; total structure of design is important, but without this SW development can be started. Waterfall type SW development can even proceed Small start, but it accompanies not a small risk.	2. 超高速開発の優れている点: 超高速開発が及ぼす３分野 <表2-1> エンジニアリングへの影響       <表2-2> プロジェクトマネジメントへの影響   <表2-3> スキルへの影響         リポジトリ中心の作業         UML表記法は不要     品質確認が容易         <表2-4> リポジトリによる整合性チェック データ項目の機能、画面、DB CRUDのチェック 業無プロセスで使われるシステム機能の確認 データ項目毎の機能確認     影響分析が簡単   プログラムはリポジトリの設計情報から生成     単体テストは不要     統合テストは自動実行     信頼できるドキュメント     実証パターンに基づくシステム開発   容易なプロトタイプ開発 異なるソフト開発   小規模スタートが可能   <下図2-5> 労働集約型と超高速開発ツール利用の場合の相対比較% 相対投入人数 工数配分比率 期間配分比率 絶対工数は労働集約型に比べ50〜10% 超高速開発はコーディングなし；その分労力を上流・下流に注力
>Top Relative ratio of Man-power, Jobs, and Period done by Conventional and Rapid methodology: (%) <Figure-2-5>
>Top Change of method of Quality Management (QM): Rapid SW development tool guarantees a certain level of quality by automatic support function of standardization, integrity, and traceability. System designers themselves can recognize errors and amend them. The tool compels designers to do so, of which some engineers feel nuisance-troublesome-annoying-irksome. >Top Change of organizational structure: Project team for SW development should be matrix structure, because many factors relate each other, such as function, screen, DB, parts, UI resource, and also architecture, server configuration, arrangement of SW. Repository requires any structure of the team to be more interactive with realtime sharing design information by each members. Stay in one's shell typed engineer is not welcome. >Top Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. >Top Change of communication: Engineers are not allowed stand-alone works. Always sharing of information enable to find problems earlier, get neutral evaluation by others, improve quality of jobs. Better communication skills are required among all members. >Top Visualization of project perspective: Project perspective is visible; the project member can report the exact situation-quo to the management, if required. In trouble case, it it important to grasp the exact situation to prepare the most appropriate measures. >Top More exact progress report: In EVM (Earned Value Management), exact grasp of EV is the key. How define the completion of jobs; by the engineer-involved or by any other neutral or objective judgement? Any job has the relationship with other jobs; how to confirm the integrity of both jobs? Due to the feature of repository, completion of one function is the result of integrity of all other related factors like function, screen, DB, etc. >Top More rapid decision making: # Reasons of difficulty of decision making: 1 Uncertainty of confirmation on facts 2 Uncertainty of ToBe model; uncertain future 3 Ambiguity of decision making process; a decision is easily overturned 4 Ambiguity of decision criteria and its criteria (Cost performance, Easiness of use, Competitive advantage, Stability, Innovativeness) 5 Endless pursue of completeness; ambiguity of goal setting Making prototype is helpful to make quick decision making. In Rapid SW development, agility is more valuable than completeness; pursuing more businesslike solution. Appearance can be improved later, and Manual handling of exceptional cases is rather speedy and surer. Rapid SW development tool has the affinity for try and error. >Top Decrease of indirect jobs: Conventional IT system development requires lots of indirect jobs, such as 1) Regular meetings, 2) Progress report meeting, 3) QM review meeting, 4) Risk Management meeting, etc.: Half of working times are spent for such indirect meetings. All meetings require to prepare hand-out or reports. Members might feel that the end of such meeting is the end of job?! Major object to have such meetings are to 1) grasp status-quo of the project, 2) improve design quality, 3) estimate EVM Repository of Rapid SW development tool can tell more exact information against such questions. Do less indirect and more direct jobs! >Top Change of estimate level: In Rapid SW development, program coding and unit test become almost zero. # of Man power: Labor-intensive development is increasing in labor, while Rapid development is almost flat. # of Jobs: Labor-intensive development needs maximus in implementation (coding) job, while Rapid development can distribute jobs other jobs than implementation. Period: Both development show similar distribution, except period of implementation in Rapid development. Absolute # of jobs (workload, or man-hour) of Rapid development would be between 50% and 10% of Labor intensive development. (estimated about 40 cases) These statistics is really valuable both for Vendor and User; Vendor can analyze themselves, and User can know the reality of Vendor's estimate.	品質管理方法が変わる     組織体制が変わる       アジャイルSW開発宣言     コミュニケーションが変わる     プロジェクトの実態が見える     進捗報告の精度向上         意思決定が迅速化 なぜ意思決定が遅いのか           間接作業が減る なぜ会議が多いのか         見積基準が変わる
>Top What skills are required in Rapid SW development? Skills of Business Analysis: There are three types of Rapid SW development tools: Automatic program generation in Java, C++, etc. Automatic generation of intermediate language, and execution engine can interpret it. Execute directly access and interpret contents of the repository In any case of the above, program coding ability is not required. Engineers are required to skillful of at least understanding computer program. Conventional engineers are required not only programing ability, but also understand 1) abstraction skill, 2) cohesion (or strength, or degree of collaboration) of related functions), 3) coupling (degree of coupling among related modules, or degree of independence or severalty of the module) , and 4) modularity (strength of division of a network into modules). Modularity: Networks with high modularity have dense connection between the nodes within modules but sparse connections between nodes in different modules; often used for community structure in networks. biological network (animal brains) exhibits a high degree of modularity. Automatic generation needs not such skills, which lower the stakes of programing, and contribute rapid development. On the other hand, more skills of ability of analyzing business activity, consider about meaning of data, and find out solutions; i.e. 1) Business Process, 2) Work Flow, 3) Data Model, and 4) making Output >Top Idea of Data-centric: How to manage data? It is the Data which connect Business model and SW model. Data-centric (or Database-centric) emphasizes; Business activity is to take good information and abandon bad one, then analyze and proceed them to fulfill the business object, then deliver the batch of jobs to the client. DOA= Data Oriented Approach; (Conventionally; or ER (=Entity Relationship) Model: One fact one place Cf: POA = Process Oriented Approach is the opposite concept; designing according to the business transaction flow; may cause data duplication and less maintenanceablity. >Top No need of learning previous design method: Conventional design method emphasizes the importance of making Design Architecture. But of real expert can make such design architecture. Actually easier and more practical designing is useful; Evaluation of IT system is shifting from technical viewpoint to more business viewpoint. Conventional SW development method tends to pursue the limit of making abstracted or generalized functions; Automatic generation needs not such consideration. Development of EV needs not make engine unlike gasoline vehicle. >Top More importance of communication skill: SW development requires, 1) function design, 2) DB design, 3) UI design, and 4) Operation design. (Conventional large-scale SW development requires additionally 0) Architecture design) Rapid SW development team has no vertical divisions, unlike conventional development team; thus more horizontal communication is needed. (Open-minded collaboration) >Top Need of how to use the tool: Learning of Rapid SW development tool is not so difficult; usual business person (of IT division or end user of User company) can master it, without having computer scientific background.	求められるスキルはどう変わるか 業務分析のスキルが重要 Modularity＝ヲタク度？                 データ中心の発想     従来の設計手法は不要       コミュニケーションスキルが重要     ツールの使い方の習熟
>Top Using Rapid SW development tool: Quesi-Agile Development type: preferable for small-start project Simplified Waterfall Development type: preferable for long-term using stable project; adopting DOA (Data Orientated Approach) with incremental improvement. Both development type adopts incremental improvement. Quesi-Agile Development type emphasized agile development; preferable in developing changeable application; Reposition is not essential in this type. Backbone (core) system needs to be used long-term & stable operation; Repository become important in this system. Rapid SW development tool is also used as Prototyping tool; able to show last image of the system to User in Requirement analysis stage. >Top Request For Proposal (RFP): Various methodologies in earlier stages, which vary among Vendors, consultants, etc. But almost all Rapid SW development tools adopt DOA methodology. Data analysis matters; even when using UML or BPMN (Business Process Modeling Notation). DOA is effective to shortening development period, and also decision making, and quality risk evaluation. Prepare for Rapid SW development: In 1980s: Japanese companies almost finished IT system development by Mainframe; Mini- or Mid-range computer or Workstation ( so-called Ofukon in Japan) with proprietary OS. In US; Mini-computer include SBC (Small Business Computer) which derived from Mini-computer. In Japan; Mini-computer and SBC are regarded as different category; the former is scientific use, while the latter is business use for mainly SMB. In 1990s: Client/Servers, then Web application age; in a boom of rebuilding core system. But long-term operation of the system without revision means increase of obsoleting ratio; decreasing the effectiveness. In the last 15 years, backbone systems could not have been rebuilt; probably because it is too expensive, too much unmanageable or out of hand, and insufficient succession to the next generation. Thus there is a reason of the advent of Rapid SW development method at this moment.	超高速開発ツールを使う開発 <左図>：簡易WF型 超高速開発ツール使用による開発行程の例 (リポジトリー有) 簡易WF型とは、一部の機能からインクリメンタルに開発していく。   DOA (データ中心のアプローチ)の採用 ビジネスプロセスの明確化 データの集まりの分析が必須 上流工程で超高速開発ツールを使うメリット 作業時間の短縮；意思決定の短縮；品質リスクの低減   RFP (要件定義)の作業が従来と大きく異なる   超高速開発への準備 1980年代の開発 1990年代のC/S→Web開発
>Top 3. Practices of Evolutionary Prototype Development: Problems of Waterfall type SW development: Waterfall type development gives advantage to Vendor; Divide each development stage and get written confirmation of each completion stage from User; Acceptance of No-Return unless extra payment. Recent IT system contains rich GUI, which may increase man-hour. Are there any Users who can understand and accept the system only by drawing of design? Real RFP appears in later stages, which will be a cause of trouble. Venders delivered business computer (called Office Computer in Japan) with application and source code to User. The SW (together with source code) delivered to User is rather templates, which resembles to 'Evolutionary Prototype SW development. Present package SW is supplied without source code, just like in a black box; also requiring certain maintenance fee and version-up fee totaling (around 15-18%) >Top Package SW increased further confusion and spoiled SW development method: In 1990s, ERP package SW emphasized Fit & Gap Analysis; which is only effective in the case of No-Gap or very little Gap. Particularly, Japanese companies tend to require much customization to package SW; causing nearly equal or even more expensive compared to making from the beginning. (E.g.. Dispute between IBM and Suruga Bank) 'Evolutionary Prototype SW Development' Making Prototype is remarkable, but has a limit. SW Prototype looks like 3D printer in production; Visual confirmation by prototype is common in manufacturing and construction industries; which has not been yet used prototype in confirming User's request. Disadvantage: Venders prepare qualified project manager to analyze User's work flow. After checking prototype, User's request may swell infinitely which Vendor must curb such inflation of requests to a reasonable level. Until now there have been no efficient tool to make prototype. >Top Two types of Prototype: Disposable prototype; like making mock-up Evolutionary prototype; can evolution by repeated revisions to production type; Tool which has smart revision function is needed. Output of each stage doesn't matter. Project Management ability matters, otherwise man-hour and period be elongated. How to use Rapid SW development tool: Define 1) work flow, 2) data item, 3) logic in repository; >Top Making screen design (GUI design) requires some skill and sense; templates of GUI will be useful. In a short period, one can make prototype, which will evolve. (Evolving Prototype) Specification will be determined using the prototype; avoiding insufficiency or omission of specification. Making design document is also made using the repository. The author feels that the project cost and period could be halved compared with conventional method. There is no difference between making prototype and production type. First, work flow designer or consultant analyzes target of the work flow, and makes a work flow of the new system; then examines data items. After determined data items, then design input screen, retrieve screen, output screen, and define and register transaction rule or calculation logic concerning the data items to the repository. >Top Comparison of development costs of various methodologies (User's viewpoint):	3. 進化型プロトタイプ開発の実践: WF型ソフト開発 ステージ毎の文書確認   Data Item (Sample) # Field name attribute digit deci- mal 1 Company code Num. 5   2 Company name Char. 20   3 Post code Num. 7   4 Address Char. 60   5 Phone # Num. 10   6 Regi. date Calen. 8   7 Regi. PIC code Num. 3   8 Regi. PIC Char 10   9 Class. code Num. 3   10 Class. name Char. 10   11 Min. profit ratio Num. 4 3 12 Credit limit Num. 16 0 PKGソフトが更に混乱に拍車 分析       プロトタイプは２種類ある 進化型プロトタイプ開発 各ステージでの文書化はさほど重要ではない プロジェクト管理能力が重要           開発手法別開発コスト比較 <左図> GUIデザイン 進化するプロトタイプ プロトタイプ型開発が最安           ユーザの視点:
>Top Describe Work Flow Chart: Following chart is a rough sample of a typical manufacturer. 'Rough' chart is so far enough, which will be refined and detailed. There are special drawing tools of work flow chart and data definition; but it is enough to use already mastered tool to write down the rough chart; Thereafter, expert engineers of Rapid SW development can finalize the chart using their accustomed tools. >Top Exception and error handling: In making prototype, exception and error-handing routines are a kind of taboo or unlucky corner; these process cannot be neglected, but these may make the user delayed in confirming the requirement. >Top Is this useful for Management Accounting?: Conventional IT systems have been made for business transaction; but from now on it should be also useful for Management Accounting: Classification attribute for aggregation or retrieval from management point of view is getting more important. In some cases, prototype of prototypes should be needed for the user who may recognized the necessity of attributes after getting images by a preliminary prototype. Digit numbers could be important; some cases make the digit code have particular meanings, which need lengthy digit numbers. If the code which has no meaning can be shorter digit numbers, but needs additional attribute for classification. Database Normalization is not so important in using Rapid SW development. DB Normalization: is the process to minimize redundancy by dividing large tables into smaller (less redundant) tables. The objective is to isolate data so that additions, deletions, and modifications can be made in just one table. (1:N relationship) >Top Screen design: Web technology is increasing the idea of scree design, like easy-to-use and impressive screens (pull down menu, color coordination, responsive, visual, etc.) Conventional screen of business computer and that of Web interface are totally different; idea and objective are different. Vendor propose User either to accept I/F of the package SW, or huge customizing fee for changing I/F. Prototype is useful to get confirmation from User regarding Calculation logic, Data quotation rules, etc. Access Permission must be confirmed from User. Workload of making prototype: Prototype must be made easily and speedy, say, 2 -3 man-months as an average based on rough work flow. Conventional development method has shelved intentionally to make prototype.; But Rapid SW development took prototype a close-up. User's assertion of prototype may change ambiguous attitude of Vendor.	業務フローを書く       <左図> プロトタイプ業務フロー(例)                   例外処理とエラー処理は鬼門     管理会計に役立つか 集計用・検索用の属性分類コードを整理 場合によってはプロトタイプのプロトタイプが必要 コード桁数に意味を持たせるか？ 意味なしコードの場合は、別途属性分類コードを追加 データの正規化       画面設計       プロトタイプ作成の手間
>Top Problems of Rapid SW development: >Top Business know-how is needed to complete Work Flow: Work Flow must be made eventually in either conventional method or Rapid development. Engineers in 1980s involved in development Mainframe or Business Mini computer were trained to understand typical work flow. Users know their own work flow substantially in depth. Why present Vendor knows little about business work flow? It may be due to too much dependance on package SW (particularly ERP package and business package), which has ready-made standard work flow. Thus vendors need not analyze User's work flow any more. (Function geek?) Root of ERP: developed from MRP (Material Requirement Planning) -> MRP2 -> ERP Internal senior engineers of manager class had experienced work flow to develop SW for Mainframe or Business mini computer; who retain invaluable know-how of analyzing work flow. >Top Business Management System: Business Management System to support top management seems most difficult to build. Japanese top executives rarely retrieve management data from DB; who usually check summarized Excel data prepared by the staff. MIS (Management Information System), DSS (Decision Support System), or DWH (Data WareHouse) appeared but disappeared soon. Japanese industrial culture may cause these phenomena; major companies do their business subject to their holding company and government, i.e., subcontractor in broad meaning. The most important thing of subcontractors is the obedience to their parent organization, behave like Chief Obedience Officer. Most of major companies are satisfied with utilization of IT System as a means of efficiency of the field activities. Some major B2C companies and companies who have maniac IT staff are exceptions. Solution: Top executive themselves should recognize what data and analysis Business Management System be useful, looking the prototype screens, if needed, together with management consultant.	業務フロー作成には業務知識が必須           どうやって経営管理するのか 日本の多くの大企業の実情 親会社依存の経営体質         経営者はプロトタイプを画面を見ながら経営情報のあり方を研究すべき
>Top 4. Problems and impact of Rapid SW Development: User initiative in SW development is increasing; Followings are issues to be prepared for the coming new age: >Top HRD (Human Resource Development) of User company Organization and mindset of User company Role & function of mid-sized Vendor in Rapid SW development age Transfer from present system to Rapid SW developed system Cultivate HR who can use efficiently Rapid SW development tool. Skill of business process analysis is a competency of the organization. The skill level is not so high grade, as long as by using Rapid SW development tool. Outsource to external consultant is probable, but the responsibility remains the assigner (unlike dumping everything on). Sensitivity for risk is also important. Top management should enhance awareness of User's initiative: As the ranking of OECD indicates that Japanese top management are not aware of the importance of IT. Actually, the ratio of IT investment is lower among OECD. IT stands for a collocation of Information and Technology. In Japan it is regarded as a matter of technology; Information is know-how or tips of Technology, which should be learned by technical-oriented people. >Top But IT means as 'Information derived from the use of Technology'. (I derived from T) what is or how to treat (know-how or tips) technology. IT contributes improvement of PDCA cycle of business activity. → Fusion of IT and Management There are many 'uncontrolled or unmanageable' IT systems in Japanese companies. >Top Cost comparison of Conventional SW Development vs. Rapid SW Development: <Right Chart> Rapid SW Development is much cheaper than Conventional development. Type-1 (Only 10%): User purchase Rapid SW Development tool and promotes in-house development by internal staff. But there are differences in ability of using the tool. Type-2 (25%): User promotes in-house development getting support from the tool vendor as consultant. This style is practically effective in making rather small type of SW development. Type-3 (50%): To promote large-scale or core system by Rapid SW development, contract Si Vendor, who makes not only the required system, but also necessary document, etc. >Top Entire organization should participate in utilizing information: User of IT system (End User) is all in the organization. End user play vital role in planning improvement of the IT System. Conventionally completion of the system (Cut over) mean the end of Vendor's job, but it is the start of the user's job, who will play major role in accumulating information for the next step of improvement. For the user, it is more important Rapid Utilization rather than Rapid Development. Change of function of Human and Computer: <Right Column Chart> Computer can handle digital information only (until the advent of really wise AI), and show enormous ability in huge volume of processing. Human can handle both analog and digital information; and both typical and atypical jobs. Human shows more interest in atypical jobs; getting tired of one-pattern job. (There might be some exception.) Humans can learn if they have a will, while Computer cannot (at least for a while. because Computer can act according to the instruction of SW which Humans made.) Both Human and Computer can act complimentarily and contribute the corporate goal. a Impact to Mid-sized IT Vendor: Belonging of IT engineers of User company vs. Vendor; 72 : 28 in US, while 28: 72 in Japan. (The ratio is reversed!) Japanese mid-sized IT Vendor tends to become subcontractor of a big IT Vendor rather prime contractor of User. >Top Such subcontractor or sub-subcontractor system is called multi-layered or hierarchical structure of IT industry, which is a serous controversial issue in Japan. One reason would be that big IT vendor plays an insurance function; in case that subcontractor could not afford to complete the project or were enforced to remake the project, then the prime contractor (big Vendor) would cover the insufficiency of fulfillment. This is a defacto insurance function in IT industry. User company can claim or sue the prime contractor for the breach of the contract. Big Vendor will respond to the request of the user usually considering long-term business relationship. (Relation-based negotiation peculiar to Japanese traditional business style.) May IT investment increase? Some IT Vendors who hire lots of programmers worry about the shrinking of business market due to the diffusion of Rapid SW Development tool. Though investment amount per project surely decreases, opportunity of project increases; the total pie of IT investment become bigger according to the Rapid SW development. >Top Transformation from Vendor to Partner: It is a good opportunity for Vendor to become Partner for the User, strengthen the following ability: Project management skill Human communication Team building ability such as facilitator or coordinator Wide range of know-how peculiar to each industry >Top Transfer from conventional system to Rapid SW development system: Research of the present system, and register to the Repository. (Legacy system have several thousand programs.) If the programs are written by COBOL, reverse engineering tool is available; extracting relationship of data items and automatically register to the Repository. Building Repository is more preferred than proceeding reverse engineering of codes. The reverse engineering jobs can be focussed to major functions. Asking external specialist of making repository is useful. The repository which reverse engineering tool makes and the one which Rapid SW development tool makes usually have different format. Repository conversion tool can be expected according to diffusion of Rapid SW development.	4. 超高速開発の課題と対策: ユーザ主題の超高速開発 人材育成 組織体制意識づけ 中堅ITベンダの歩む道 超高速開発への移行   経営トップのイニシアティブ 日本のIT活用は先進国の下 そもそもITとは技術問題ではなくて経営問題 I. derived from T. ITははビジネス活動におけるPDCAの改善 →ITと経営の融合   組織全体での情報活用の取組み   人のコンピュータの役割変化               兆時台の中堅ベンダの進むべき道   下請けビジネスの市場は縮小   IT投資は増加する   現行システムから超高速開発への移行   リバースエンジニアリングによる可視化   レポジトリの作成 様々なリポジトリ レポジトリ変換ツール   ベンダからパートナーへ
>Top 5. Cases of Rapid SW Development: Developing any project, it is necessary to clarify the Ends, Means, and Requirements: particularly to recognize 'To-be' model is important: Correspondence Table of As-is Model and To-be Model: Ways Problem Cause As-is To-be Effect Objective Making Info. DB Takes time to find past data Old files (>2yr) kept in warehouse Nuisance, & losing time Accessible to old files Cut indirect job; 2hr/d Business upgrade Unclear situation of other dept. Necessary info is not available now Takes time to collect info. Make info report immediately Cut indirect job; 2d/man-mo Business upgrade >Top Key to success factor of Rapid SW Development: Making Prototype User has mastered Rapid SW development procedure getting necessary technical transfer from Vender. Case Study from success of front runners.	5. 超高速開発の活用事例::
>Top Case Study: Case # User company Vendor Project/System Remarks Name Est. Capital (¥M) Business Emp. # Tool 1 TMJ Inc; (Benesse, Marubeni) 1992 300 ・Call center operation 418 +8,000 Wagby (Jasmin Soft) ・OL resale business call center support system ・ Order/Catalog/Inquire Acceptance system ・Project team 5 2 Meijiza Co Ltd 1873; 1950 200 ・Theatrical production 129 Xupper (JBCC) ・Seat reservation ・ Lunch business support ・5W2H (+how many) Designer is a story teller. ・ Repository ・ Recognize value of DB field ・ HACCP authorization 3 Konno Corp 1961 1969 30 ・Manufacture ・Toe-lift jack 30 Contexer ・Inventory management ・ Repair estimate management ・Uniform control of estimate data (PDF, etc) ・ Work progress status ・ Make-To-Order 4 JA Ishikawa Keisan Center192 1977 192 ・JA Data processing ・Housing ・Hosting ・ Compass-JA operation 40 Sapiens ・Purchase & Sales management with JA farmers ・System cost 36% of MF 5 Fujitsu Ten Japan (Fujitsu, Toyota) 1972 5,300 ・Info-tainment ・Car audio ・Navigation ・Home audio 3,399 Magic ・Design system by PDM ・ Overseas production ・transferred Oracle eBusiness Suite (EBS) 6 Asahi Intec Co Ltd. 1976 4.214 ・Medical device manufacturing ・ultrafine stainless wire 393 StiLL ・Asset management ・A/C receivable management ・ Credit limit management ・VBA like operation ・Excel function usable 7 Ikiiki Medicare Support 2011 20 ・Rehabilitation service ・Home nursing service   GeneXus ・Home nursing service management; smart phone support ・Development period: 2010/9 - 2011/4 (8mo) HACCP: Hazard Analysis Critical Control Point; food sanitation JA: Japan Agricultural Cooperative; Finance & Insurance is the big service, which was shift to JA national center. PDM: Product Data Management System DOA: Data Oriented Approach VSS: Microsoft Visual SourceSafe; now TFS (Team Foundation Server) VBA: Visual Basic for Application
>Top 6. Rapid SW Development Tool List: ★ means the member of Extremely Rapid application Development Commnity (xRAD): These tools can be categorized by the investment amount of User (annual expense of IT system) and the involvement of Use (ability of IT literacy). These mapping relates to the degree of dependency to Vender and aggressiveness of User. # Tool Name Vender name developed in Applicable to System generation Reposi-tory 1 A's Style KMK World Inc. Japan All Bz app. Yes ★ 2 ASTERIA WARP Infoteria Japan Specific Data combi. Yes ★ 3 BP Logix Assist Micro US All BPMS Yes   4 Business Process Management Suite Oraclec Corp. Japan US All BPMS Yes   5 BusinessWare VITRIA US All BPMS Yes   6 Contexer ApstoWeb Japan All Bz app. Yes   7 DataSpiderServista Appresso Japan Specific Data combi. Yes   8 GeneXus Genexus Japan. Urguay All Bz app. Yes ★ WeING; JMAS; 9 iLOG IBM Japan US All BPMS Yes   10 intra-mart NTT Data Intra-mart Corp. Japan All BPMS Yes   11 iRYSHA Gyomu Control Technology Inst. Japan All Bz app. Yes   12 innoRules Earnest Business Solution Co., Ltd. Korea Specific BPMS Yes   13 Jboss Red Hat KK US Specific BPMS Yes   14 Magic xpa Application Platform Magic xpi Itegration Platform Magic Software Japan Israel All Bz. app. Yes ★ 15 Metasonic Suite Metasonic AG Germany All BPMS Yes ★ Powered Process Consulting 16 NetWeaver BPM SAP Japan. Co. LTD. Germany All BPMS Yes   17 ODIP Intelligent Model, Ltd. Japan Specific Batch dev. Yes   18 Open Text Cordys Open Text CORDYS Netherlands All BPMS Yes   19 Outsystems Platform BlueMeme Inc. Portugal All Bz app. Yes ★ 20 Pega SmartBPM Pegajapan KK US All BPMS Yes   21 PEXA Suite Atrris. Corp. Japan All Bz app. Yes ★ 22 Questra BPM Suite Questra, Inc. Japan All BPMS Yes   23 Rakuraku FrameworkII Sumitomo Electric Infomation Systems, Inc. Japan All Bz app. Yes   24 Sapiens Sapiens Japan Co. Israel All Bz app. Yes ★ Komakusa 25 seap Jena Co., Ltd. Japan Specific Others No ★ 26 STAR-ATT/STAR-Lite Frontes Japan Specific Test sup. Yes ★ 27 StiLL-X ILI Research Institute Japan All Bz app. No ★ 28 TALON Falcon Co. Ltd. Japan All Bz app. Yes ★ 29 TERASOLUNA NTT Data Japan All Bz app. Yes   30 Tibco Business Process Management Tibco Software Inc. US All BPMS Yes   31 Unicage Universal Shell Programming Lab. Japan Specific Others No ★ 32 Wagby JasmineSoft Inc. Japan All Bz app. Yes ★aPride; ★CIJ Next; ★FFSOL; ★Infront; ★NCD; ★Palsys; ★SP; ★Zeat; 33 Web Performer Canon Software Inc. Japan All Bz app. Yes ★ 34 WebMethods Software AG Germany All BPMS Yes   35 Xenlon TIS Inc. Japan All Bz app. Yes   36 XupperII JBCC Corp. Japan Specific Design sup. Yes ★

Comment

This book is written through activities of ICT Management Partners Association, or ICTMP. This book can be called a product by "Intelligence Collective Team Members Participation"

本書はICT経営パートナーズ協会の活動の中から生まれた。 いわばメンバーの集合知である。つまりICTMPは "Intelligence Collective Team Members Participation"ということになるのだろうか