From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 22 Jan 93 07:33:25 GMT From: agate!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!geraldo.cc.utexas.ed u!emx.cc.utexas.edu!not-for-mail@ucbvax.Berkeley.EDU (Ravi Kalakota) Subject: Why and how do organizations select the OO approach to S.E Message-ID: <1jo805INNfe@emx.cc.utexas.edu> List-Id: (A shorter version of this was posted in comp.object and comp.software-eng) Why and how do organizations select the OO approach to Software Eng. I have been going though the software engineering literature (primarily OO literature) to understand and enumerate the reasons why organizations, firms or groups have chosen or were seriously thinking about using an object oriented approach to software engineering. There is an amazing lack of objective, evaluative literature on the selection of methodologies in software engineering. We seem to be carried away by the bandwagon effect and are not spending enough time understanding the pluses and minuses of new methodologies, their effectiveness in various types of application development areas and their effect on people. I may sound pessimistic but it is definitely time that we understood what external factors impact the selection of methodologies and what impact does the selection of a methodology have on the effectiveness of the development group. While the technical side has progressed and is progressing, the management side is limping along with lame theorizing which almost always has no practical value. Most authors also seem to be consultants and each of them is pushing his or her own methodology without any assessment of how or why it better than the other available methodologies in the market. Most of these people seem to be interested in making a quick buck before the "fad" loses its charm. These people come across as snake oil salesman rather than objective people. Milt Fulghun points out that at OOPSLA'92 that there was a noticeable hunger for application and experience papers, panel sessions and workshops. How are we satisfying this need? The best people for the kind of research which bridges the managerial aspects with the technical are the people on the "western front", managers. Unfortunately, most of them don't have the time to dissipate or write about their experiences and this is one of the reasons why we are suffering. We are unable to reuse the knowledge of the software engineers and project managers. Hence this plea, I urge this group of people to share with me and others the knowledge which would answer the following questions: 1. What are the factors that were considered and evaluated before you decided to select an object oriented approach to software engineering? I have found four broad categories: monetary, technical, organizational and political. I have included personnel training and selection in organizational category. I would appreciate your filling each category and suggesting more categories if these are not sufficient. Milt Fulghun (fulghum@esds.mdc.com) response to Question 1 was the following: > Our primary reason for going to object orientation is that object > partitioning maps well into our application space, visual simulation. > We believe that object oriented software will be easier to maintain in > our environment. According to Steve Berczuk (berczuk@space.mit.edu) > In the 2 projects I have worked on so far, the primary factor in selecting a > methodology was (yes, this is serious), what methodology (novice, until the > time of taking a course in OO) THE DECISION MAKER SAW in the first course > that he took on Object-orientation. Both times there were others in the > project who had been building OO systems for at least a few years and were > at least familiar with some of the OO methodologies, and these experienced > people would find the choice to be wrong for various reasons. 2. What impact does the selection of object oriented methodology have on the project sucess, customer satisfaction and learning for future projects? I assume there are other factors other than the ones in Q1. which moderate this relationship. According to Steve Berczuk (berczuk@space.mit.edu) >The methodology should be used to facilitate the DESIGN process as WELL as the >documentation process. Probably the biggest problems arise from taking the >phrase "We'll use the XXX methodology" to mean "We'll use the symbols in the >XXX methodology" rather than using the methodology to explore the system. With regard to Q1, I have found some stock or canned answers, such as: - software reusability (both code as well as design) - easier maintenance (mainly perfective and adaptive) - faster time to market, by compressing the product lifecycle - ability to perform concurrent and parallel development - enhanced interoperability (??) - reduction of code complexity through encapsulation and information hiding - better suitability for real-time systems. However, probably the most common answer would be: software reusability. But to implement software reuse, you need a clear organization policy to make it a sucess. How many organizations have such a policy and enforce it in practice? Does one come up with a policy before selection of methodology or patch quilt one as one goes along. Ed Berard puts it very succinctly in his book "Essays ...." " Like object-orientation, software reusability is very much misunderstood. Many people think that the pinnacle of software reuse is a "library of math functions." What most software professionals do not realize is that software reusability, like object-orientation, impacts everything, from management practices to software development standards, and much more." Please email your thoughts to me and I will summarize, if people are interested. Send your comments to kalakota@emx.cc.utexas.edu Thanks in advance, -- Ravi _______________________________________________________________________ Ravi Kalakota University of Texas at Austin Austin, Texas 78712 kalakota@emx.cc.utexas.edu _______________________________________________________________________