ryuji@lsa.ncl.omron.co.jp (Ryuji YAMASAKI) (03/26/91)
In article <511@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: >Can you share any information on how software is being written in >Japan? Is it fairly monolithic, or are different techniques and >process models (software engineering methodologies) being tried? As far as I know, people are seldom applying software engineering methodologies in Japan. Few people are trying some methodologies for Software developments and others are just watching where they are going. Historically, any kind of software such as computer software, services, or knowledge was considered free of charge or cheep to get, in Japan.. Thus, Japanese firms were focussing on Hardwares developments. Many companies in Japan have their own standard in documentations and/or methodologies in building softwares but most of them were copied from that of IBM's or of other companies in US. In OMRON's example, we had a standard based on iPT(Improved Programming Technologies) from 12 years ago and hasn't been modified since. I am now renewing based on Structured Analysis and Design. After 1985, various CASE Tools have been introduced in Japan and people started to recognize the importance of `Software Engineering approach'. Now we have conferences and discussions everywhere. But very few companies have succeeded in instroducing software engineering methodologies inside. Many conflicts in job process. >Are people and companies in Japan applying statistical quality assurance >(i.e. Demings, Juran, and others) to software development? Quality metrics? In my company, we've just made a `Quality metrics' table for software products last month. I am just at the entrance of this field but I am trying to watch the trends in Japan and in the world so that I can imporove software developments in my company. -- _______________________________________________ :|Ryuji YAMASAKI :|OMRON Corporation. Kyoto Japan :|junet : ryuji@lsa.ncl.omron.co.jp :|uunet : ryuji%lsa.ncl.omron.co.jp@uunet.uu.net :|Tel : 075-951-5111 ex-3109
alan@tivoli.UUCP (Alan R. Weiss) (03/29/91)
In article <RYUJI.91Mar26142145@tandem.lsa.ncl.omron.co.jp> ryuji@lsa.ncl.omron.co.jp (Ryuji YAMASAKI) writes: > >In article <511@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: > > >Can you share any information on how software is being written in > >Japan? Is it fairly monolithic, or are different techniques and > >process models (software engineering methodologies) being tried? > >As far as I know, people are seldom applying software engineering >methodologies in Japan. Few people are trying some methodologies for >Software developments and others are just watching where they are going. >Historically, any kind of software such as computer software, services, or >knowledge was considered free of charge or cheep to get, in Japan.. Thus, >Japanese firms were focussing on Hardwares developments. This is interesting. We in the American software industry keep hearing of the prolific, bug-free Japanese developer/engineer who often completes 200 - 300 lines of defect-free code per day. Can you verify this for us? Is the 5th Generation Project dead? >Many companies in Japan have their own standard in documentations and/or >methodologies in building softwares but most of them were copied from that >of IBM's or of other companies in US. This used to be true in America (for example, the Unisys Phase Review is a copy of the IBM Plan of Record process). I believe that it is no longer the case, as independent researchers such as Barry Boehm, Watts Humphrey, the SEI, MCC, and literally thousands of software firms create their own methodologies. >In OMRON's example, we had a standard based on iPT(Improved Programming >Technologies) from 12 years ago and hasn't been modified since. I am now >renewing based on Structured Analysis and Design. Ed Yourdon and Tony DeMarco's Structured Design/Analysis/Coding is still very popular here, but being adapted to rapid-iterative, Spiral, and other models. We're seeing the object-oriented paradigm forcing a reinvestigation of process models, too. Fundamentally, the software architecture tends to drive the process (form follows function, so to speak :-) >After 1985, various CASE Tools have been introduced in Japan and people >started to recognize the importance of `Software Engineering approach'. >Now we have conferences and discussions everywhere. But very few companies >have succeeded in instroducing software engineering methodologies inside. >Many conflicts in job process. CASE has taken root in America, too, although more for application development than system software. As for getting software engineering principles adopted within your compnay .... join the club! THAT is the KEY ingredient in improving quality, and it is difficult. It would be useful, perhaps, if you tried experiments with smaller groups, and build upon your success and learn from your mistakes, rather than trying to revolutionize the entire company. > >Are people and companies in Japan applying statistical quality assurance > >(i.e. Demings, Juran, and others) to software development? Quality metrics? > >In my company, we've just made a `Quality metrics' table for software >products last month. What kinds of metrics are you using? Can you share this information, or is it too proprietary? > >I am just at the entrance of this field but I am trying to watch the trends >in Japan and in the world so that I can imporove software developments in >my company. Your intense interest will surely lead you to success, but remember that SQA is a young science. Keep at it, and keep trying to improve the profession as a whole. > >-- > _______________________________________________ >:|Ryuji YAMASAKI >:|OMRON Corporation. Kyoto Japan >:|junet : ryuji@lsa.ncl.omron.co.jp >:|uunet : ryuji%lsa.ncl.omron.co.jp@uunet.uu.net >:|Tel : 075-951-5111 ex-3109 _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 "I speak only for myself, not for TIVOLI" _______________________________________________________________________
laub@Software.Mitel.COM (Boniface Lau) (04/02/91)
In article <519@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: |In article <RYUJI.91Mar26142145@tandem.lsa.ncl.omron.co.jp> ryuji@lsa.ncl.omron.co.jp (Ryuji YAMASAKI) writes: |> |>In article <511@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: |> |> >Can you share any information on how software is being written in |> >Japan? Is it fairly monolithic, or are different techniques and |> >process models (software engineering methodologies) being tried? |> |>As far as I know, people are seldom applying software engineering |>methodologies in Japan. Few people are trying some methodologies for |>Software developments and others are just watching where they are going. |>Historically, any kind of software such as computer software, services, or |>knowledge was considered free of charge or cheep to get, in Japan.. Thus, |>Japanese firms were focussing on Hardwares developments. | |This is interesting. We in the American software industry keep hearing |of the prolific, bug-free Japanese developer/engineer who often completes |200 - 300 lines of defect-free code per day. Can you verify this for us? | According to the report (actually a MIT thesis) "The Japanese Software Industry", the software technological leadership in Japan resides in the major JCM (Japan Computer Manufacturers), not the small Japanese software houses. It covers the Sigma project and the efforts of Hitachi, NEC, Fujitsu, and NTT. The report relies heavily on Japanese computer literature. -- Boniface Lau (613) 592-2122 ext. 3042 laub@Software.Mitel.COM Mitel Corp. ...uunet!mitel!spock!laub 350 Legget Drive, Kanata Ontario, Canada, K2K 1X3
cole@iccgcc.decnet.ab.com (Bill Cole, Allen Bradley CIS Div.) (04/04/91)
In article <519@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: >This is interesting. We in the American software industry keep hearing >of the prolific, bug-free Japanese developer/engineer who often completes >200 - 300 lines of defect-free code per day. Can you verify this for us? <Other stuff deleted...> I think that the last statement above needs refinement. There has been a lot of talk recently about the Software Factory approach being used by several Japanese companies. The dramatic numbers on error densities coming from Japan (specifically NEC/Hitachi) should be looked at in a larger context, rather than simply number of densities/KLOC. In Michael Cusamano's series of reports on software factories, some discussion is given to software production strategies (e.g. strategic positioning vs. contingency). Both of these strategies are rooted in the type of product being developed. The reasoning he explains is that: (Loosely paraphrased) <"successful factory-like approaches targeted middle of the market in terms of product price and functionality, stressing reusability and economies of scope in designs, methods, tools, and application knowledge, appealing to customers sensitive to price/performance (e.g. strategic postitioning). Alternately, firms in the high-end/full custom business and those making standardized packages seem to require loosely-structured, project-centered approaches that were different with each product and relying mostly on personnel who were highly skilled and knowledgeable. Unique projects and high-skill personnel are probably more expensive to manage, but this probably does not matter to the producer if customers are willing to pay high prices, or a package becomes a best-seller (e.g. contingency)."> The point Cusamano is making here is that the techniques used in a software factory approach are product-dependent to a degree. Or to put another way: Software developed for a monolithic embedded system will probably have more "errors", due to the "custom" nature (read ambiguous requirements) and stringent quality criteria applied to it; whereas ROM for a series of consumer products (e.g. calculators) has much more discrete requirements, along with potential for reuse across a family of products. These factors have a major impact on the ultimate error densities achieved in a development effort. (A question arises here on the *subjective* nature of what is "an error" - especially with ambiguous design requirements, but that can be the subject of another post.) In a larger scope, this brings to mind a question on the discussion of metrics in this group. How does the *type* of software being developed impact the interpretation of process/design complexity metrics applied to it? Having personally done some design metrics work on various types of software, I learned (the hard way) that McCabe's Cyclomatic Complexity measure has to be interpreted in the context of the software being scrutinized. Software for real-time embedded systems can have much higher complexity measures than normally accepted for non real-time graphics software, due to the platform/timing/design constraints the developer had to work within. Any other thoughts on this? [Flame suit on - fire away!] ________________________________________________________________ | Bill Cole - Senior SW Design Engineer | | Allen-Bradley CIS Div. | | 375E Alpha Dr., | | Highland Heights, OH 44143 | | (216) 646-3335 | | | | * I wish sometimes that my company *did* share my views! ;) | |_______________________________________________________________|