schultz@grebyn.com (Ronald Schultz) (12/04/90)
Much has been mentioned on the net as to how the development of OO software is significantly different than the development of software using other approaches. And so I ask, how much different is OO development from conventional development when comparing OO against other approaches from a development management perspective? Albeit from the developer's viewpoint much is changed, but from a management perspective what has changed? 1. For instance, how have you found configuration management (CM) to be different ? 2. How different is your development team organization ? 3. How is quality assurance and control different ? 4. How different are your schedules and estimating when done in an OO lifecycle vs. another approach ? 5. How are your user specifications different ? 6. If you are a contractor bidding for work, how do your OO proposals differ from your other development proposals ? At the November meeting of an IBM Mainframe User's Group (GUIDE), Dave Dykstal of IBM Rochester presented on the development issues involved in developing a cooperative processing OO interface between the AS/400 and IBM PS/2s under OS/2. The presentation highlighted the differences and conflicts between the development team's spiral model of development and the rest of IBM Rochester's waterfall lifecycle development. Simple issues such as defining 'when is the product ready to be documented?' became a critical management issue when injecting OO into a development staff. Any thoughts or comments would be appreciated. I will post a summary to the net if there is sufficient response. Ron Schultz schultz@grebyn.com 614-759-3127
johnson@m.cs.uiuc.edu (12/05/90)
One of the main reasons that people are attracted to OOP is reuse, and managing for reuse is a lot different than managing traditional software. First, reuse doesn't happen by accident. More particularly, reusable software doesn't happen by accident. Software that was not designed to be reusable isn't. Even if it was designed to be reusable, it isn't reusable until it has been reused a few times. If you decide that you are not going to WRITE reusable software but are only going to REUSE it then the impact of reuse will not be that great. You will need to schedule time for your people to learn the software that you are going to reuse (don't think that it will not take any time--it will!) and you might need to assign someone to be the local expert on the package, but the overall software process is not changed much. However, if you are going to develop your own reusable software then you will need a large change in your software process. There needs to be a group of people (usually small) who are charged with building the reusable framework that others will reuse. It is probably a good idea to have them start early, because it usually takes several iterations to get a good framework. Unless you have experienced people who have built this kind of application before, it might be a good idea to NOT depend on having a framework, since it is very hard to predict how long it will take. One way to divide up a project that I know about is to have framework designers, application class designers, and application configurers (a lousy name, I know). The application configurer is the person who talks to customers and tries to build what they want. This person wants to do as little programming as possible. If the framework does not satisfy the needs of the customer, this person will either complain to the framework designers or (more likely) get an application class designer to build what is necessary. The application class designer is more of a traditional programmer, using the framework and producing classes that fit into the framework. Usually the application configurer is in charge of testing. Large projects will have lots of frameworks, some of which will be reused by different projects. Thus, a project will need to have someone to coordinate the various frameworks. Usually a project will have a chief architect, who will do the coordination. One of the real problems of writing reusable software is figuring out who is going to pay for it. It is quite likely that there are several groups using the software, and issues of reembursement and control can be hard to solve.