|
 |
|
|
[Inspired] [Prod&Svcs] [People] [Associates] [Contact] [Philosophy] [Reference] [Clients] |
|
|
|||||||
|
Managing Methods Creatively Graham McLeod, University of Cape Town, Pvt Bag Rondebosch, 7700, South Africa mcleod@iafrica.com, tel +27 21 650 4028, cell +27 82 578 1834 Abstract Organizations have used systems planning and development methodologies for some time now. Results are mixed, with some reporting substantial benefits, and others abandoning the process without achieving the desired benefits. The fact that this can occur with the same methodology indicates that there are other factors at work. Research into these factors, and their impact on the success or failure of a particular methodology in a particular situation is now accumulating. We can learn valuable lessons from these findings to apply to engineering of new methods and management of the methods that we use. This paper explores some of these ideas, and suggests how we can balance many factors which at first appear irreconcilable. The approach includes a unique method model and management approach. Keywords: Methods, Methodologies, Management, Modelling. Computing Review Categories: D.2.9; K.6.1 Received February 1992, Accepted April 1992 1. Problems without Methods and Techniques Some highly skilled practitioners argue that methods are only a crutch for the incompetent and that they should be dispensed with altogether, since they encourage "replacing insight with ritual" -Downing, 1990 This is true if they are blindly followed without regard for their suitability and without an understanding of the intentions of each step. But there are also problems where there is a lack of methodology: Lack of Standards leads to a situation where each time a particular task is performed, the person doing it has to invent their own set of techniques and representations. This would be tolerable if every practitioner was an expert in information systems techniques and their applicability to various circumstances. In truth, these skills are extremely rare. Assuming there were sufficient experts available, there would still be problems of lost information and mis-communication where varying techniques and representations were chosen. The organization would be at risk when the experts move on to other roles, leaving an unstructured pot-pouri of great variety, which will require a vast array of skills to interpret. Lack of standardisation has serious consequences whenever information must change hands. This occurs within a project between persons responsible for different areas (e.g. technical and business aspects), as well as between phases (e.g. between analysis and design). It also impacts communication of the project with user personnel, facilities, I.S. Management and support groups (e.g. Data Base Administration). In organizations where systems are crucial to the business, they will tend over time to become more integrated and will require higher levels of data sharing [51]. Frequently, several development projects will proceed in parallel with the intent that they should integrate smoothly in production. This is impossible unless the respective teams have a common language in which to exchange critical scope, design and interface information. Poor Quality arises where there are no agreed deliverables from a task (or no agreed tasks!), and thus no performance standards for what must be produced [25, 23]. This allows serious problems to escape detection until very late in the lifecycle, when they are extremely expensive to fix [12]. Good methodologies provide an expected performance standard for every step and product, thus ensuring that quality is built in [22]. They will also normally provide a safety net in the form of regular audit or review points as the product is specified, designed, built and tested [22, 36]. This adds expense to the early phases of the project, but will normally result in savings later in the lifecycle. Low Productivity. Where there are no standards, or techniques are employed for an insufficient time, there is no chance for staff to move through the requisite learning curves and to reach high levels of output with a known technique or tool. Productivity and quality suffer as a result. Where quality is poor, significant amounts of work will have to be redone, increasing costs and lowering morale [23]. Maintenance Quagmire. A major benefit of using structured techniques in a formal lifecycle is the production of documentation. This can be in paper or electronic form (e.g. within a repository), but is essential for the successful operation and maintenance of the application [25, 39]. Since some 70% plus of the lifetime costs of the typical application occur in the maintenance area [10, 15, 37], this is of the utmost importance. If this documentation is missing, inaccurate or incomprehensible, maintenance costs can soar. The organization can be left in a position where critical production applications cannot be adapted to meet changing business conditions. Poor Estimates. Worse than the technical problems caused where no methodology is in place, are the management problems. If there are no prescribed tasks to complete a project, and we do not know what personnel or skills are required when and for how long, it becomes impossible to accurately plan and estimate projects [25, 38]. This makes cost justification farcical, and can lead to the wrong projects being tackled, or expensive project failures [28]. Also, if accurate plans cannot be constructed, then tracking progress is not feasible. Figures from Boehm and others confirm that the list of casualties is long. Unprofessional. Where the above situation exists, the Information Systems personnel will give the impression (not incorrectly) of being unprofessional. The rest of the organization, and particularly management, will regard them as a group of technologists without professional discipline or an understanding of the business. The reporting level of I.T. will reflect this, and the function will not be able to fulfill its potential within the organization. No basis for the use of automated techniques. Recent models by Humphrey and others [39] indicate that there is a maturity progression through which organizations move before they can take advantage of automating the lifecycle (through extensive use of CASE tools). The use of automated tools cannot be successfully undertaken within a culture which has not yet taken standards and methods to heart.
2. Problems with Methods and Techniques "Correct" method contingent. The success of a given methodology in a given situation is contingent upon the quality of the methodology (soundness, maturity) as well as upon appropriateness to the application domain, the political climate regarding its use, skills and backgrounds of the I.S. practitioners, effectiveness of training, and attitude of the user community [24, 6]. Technological change is extremely rapid, and accelerating. Methods proven effective in a given technical environment may prove ineffective in the next environment encountered. Changing Techniques. Techniques specified by the methodologies are evolving, and new ones are constantly emerging. Witness the recent rise of the object oriented paradigm [52]. The learning curve for a new methodology is time-consuming and expensive for an individual. For an organization, it is a major investment and may take several years, since it represents a culture change [14]. Only once significant progress has been made toward mastering the techniques and methodology can benefits be realised. Tool Immaturity. Powerful CASE tools are available, but the technology is still immature and very few tools provide a totally integrated solution, or support more than one method option or target environment [39, 31]. Methodologies themselves have limited coverage. Some address only planning, others only development or package selection. Some attempt to cover everything, and in the process become unwieldy and impossible to master in totality [31].
3. Conventional Methods Too Rigorous. Some methods have evolved from rigorous academic or mathematical descriptions of very narrow problems [45]. These are essential to push back the boundaries of what we can tackle with certainty. However, there are significant problems when we take these into practice:
Not rigorous enough. Conversely, many techniques in common use have no strong theoretical or empirical base, but are merely the collected opinions of their inventors. These are at best successful by force of personality, luck or emotional attachment: at worst, misleading and dangerous. Their attraction is that they offer an apparently simpler, quicker (and hence cheaper/less arduous) way to achieve a desired result. They should not be contemplated for situations where the desired system is critical either to safety or the organization's mission. Too Big/Learning Curve. Very comprehensive methods are large [29]. Some commercial products extend to fifty printed volumes. There is a significant learning curve associated with any methodology. It is unrealistic to expect the developer to learn and have at his disposal several methods from which he can chose one appropriate to the project. [6] Too trivial/Fragmented. Simple, easily-comprehended methods are smaller and have a reduced learning curve, but they may have limited applicability. I.e. they may not cover all phases of the lifecycle, or not offer alternatives required, e.g. package selection versus custom development [44, 35]. Slow evolution. Most methodologies are either adaptations made by the practicing organization from the work of several authors, or commercial products maintained by their respective vendors [14]. The updating of these products is typically laborious and slow. This leads to delays in the incorporation of important new techniques and concepts. This can lead to frustration amongst the user community who see that they are not keeping up with the state of the art in a particular area [42]. Supplier Dependence. Where externally-sourced methodologies are used, the client is dependent upon the supplier for changes and enhancements. Of course, local modifications may be made, but this is problematic, since these may be invalidated by the next "official" release. The organization may find itself in an awkward situation if it has made a significant investment, only to find its own and the supplier's strategies diverging. Adaptation Required. Seldom is an "off the shelf" method entirely suitable for immediate application within the organization [14]. There are always unique management and cultural implications to take into consideration. The extent to which the chosen method permits and facilitates these without a maintenance nightmare is of fundamental importance. Integration Difficulties. Where techniques and tools are chosen from several sources, the integration of these into an in-house total solution is non-trivial. It is also likely to commit the organization to costly ongoing maintenance as the respective products evolve. Techniques prescribed by methodologies evolve over time. New techniques offer attractive benefits, but significant effort is required to integrate a technique successfully with the rest of the method. For example, object oriented analysis is attractive, but how does one integrate this with entity modeling, and JAD type sessions with users? Achieving a smooth migration is very difficult, and discontinuities can severly impact quality and productivity. Tools are currently maturing to support technical tasks performed [39]. E.g. Function modeling, data modeling, process design etc. Some tools support a single method, which is implicit in the tool. Others support multiple approaches, but rely upon the practitioner to perform the correct steps in the correct sequence [13, 34]. None, to the authors knowledge, contain the method definition explicitly - with the exception of the Virtual Software Factory (VSF), a tool for the generation of CASE tools [47]. VSF allows the definition of method rules to the tool. While this is at a high level, and therefor concise and productive, it still requires unique and scarce skills. There is a need to begin introducing other tools such as group decision support software, to address the less technical aspects of the interactions during the lifecycle. A further development could be the integration of electronic mail into the process, as the literacy of the community increases and access to these facilities becomes commonplace. Technical Focus. Traditional methods concentrate upon the technical aspects of the lifecycle. This author believes that there are now many competent methods which address these issues (e.g. Information Engineering [39], Method/1 [1], SSADM [43], Tetrarch [49], Infomet [33] etc). The tougher problems to crack are the management and people aspects. This has been recognised by the development of management umbrellas to the technical methods e.g. GOLD for Tetrarch [22] and Prince for SSADM [43]. This author believes that these "add-on's" should now be fully integrated with the technical aspects into a unified approach. Joint Application Development (JAD) techniques are being widely adopted as a structured way of managing the interaction of various specialists, technical people and line staff within the lifecycle. These also need to be integrated into the process followed, as with Rapid Application Development (RAD) [39]. 4. A Proposed Solution People Focus. People are ultimately the central factor for consideration. It is people who require, specify, analyse, design, build, test and use applications. We can have the most fantastic technical tools, but we ignore human issues at our peril. If the manager cannot understand the deliverable produced, or the analyst will not use the CASE tool provided, we lose. As systems become more pervasive and critical in organizations (and outside organizations), increasing attention must be paid to social and political implications. "Culture capable" techniques must be used to create "culture compatible" applications which fit the environment and user community. It is already evident that a much greater proportion of development effort will in future be expended on engineering the user interface to products. An example of this is the current re-engineering of products for the Windows/Presentation Manager environment. Fortunately, powerful tools and standards will alleviate this problem fairly quickly. An interesting phenomenon is the emergence of methodologies which have a very strong people focus, almost to the exclusion of the technical. Multiview, in the U.K., is a good example [5].
Management Focus. The technical problems are largely solved - this is typically not where projects fail today. Most serious problems are encountered in management aspects - Planning, estimating, tracking, control, quality assurance [28]. Additionally, management is called upon to manage an increasing variety of project types: strategic planning, application development, reverse engineering, package implementation, and others [35]. There is a need for a common management approach to these, so that skills can be transferred across project types, and so that reporting and judgement can be consistent. Valuable lessons can be learned here from the Software Engineering and Configuration Management disciplines [32]. These offer a consistent set of phases, quality control points and management process for a variety of project types. Unfortunately, they incur significant overhead unacceptable in the commercial sector. This author believes that we need to make these techniques less resource intensive and educate management to accept the overhead for mission critical projects. Layered Architecture. Current methods are often poorly structured internally [44]. Like bad systems, they have confused levels of abstraction, high coupling between apparently unrelated areas of the method, and are very difficult to maintain without disturbing things unitentionally. It is a gargantuan and specialised task to integrate components from competing methods. The situation is analogous to the early days of data communications. As in this field, the solution lies in standards and layered architectures. We need to distinguish between, Philosophies, Methodologies, Techniques and Tools [31]. This allows us to keep the foundations of philosophy and management process stable while the techniques and tools evolve. Method Model. The methodology needs to be represented and stored in a structured, explicit form. The author has developed a method model for this purpose. This has four inter-related components:
The model is explicitly described and includes management as well as technical tasks. It is capable of representing a variety of methods in a consistent way for easy comparison, integration, management and maintenance. Quality Integration. Quality is an underlying philosophy and cannot be grafted on afterwards. It is implicit in every task performed, and every product produced [23]. Consequently, within the description of the method, every task and deliverable must have associated quality standards. In addition, formal quality review points and an error detection/correction scheme are built into the management process. These apply to the method itself as well as the product being produced by the project. Dynamic Lifecycle Generation. The full method is large and would be unwieldy if applied on an individual project. Consequently, techniques are provided to allow only tasks and deliverables relevant to the current project to be extracted from the model and specialised. This is achievied without loss of integrity and respecting dependencies. The specialised version then serves as the basis for project planning and management. Creative Schizophrenia. Organizations need to leverage expertise by using techniques and technologies for extended periods of time. They also need to come to grips with new technologies, select those that have significant long term benefits and begin learning these early to build expertise and define usage parameters appropriate to their circumstances. This can best be achieved by creative schizophrenia, where the mainstream production teams concentrate on using the current technology effectively and efficiently, while a separate group scans the marketplace, evaluates promising technologies, and advises on adoption and implications for technologies selected. This group has a dual role - Planning the technological evolution of the organization's infrastructure, and transferring technology and expertise to the production teams. Two local organizations practicing this approach are Old Mutual and Foschini Data.
Self Enhancing. The methodology cannot remain static over time, waiting for the next release. It must evolve and become tuned to the organization, its culture, infrastructure and technology. This can be achieved by having the method explicitly defined in the model, and incorporating method review points into the lifecycle. In this way, projects can take advantage of lessons which were only learnt in the previous phase of a concurrent project.
Consistent Management View. This can be achieved by adopting a Configuration Management framework for the project phases at a high level. This ensures that, at the management level, all projects have a similar look and feel, allowing meaningful comparisons, and accumulation of project management expertise. Detail tasks within the phases will vary dependent upon the type of project, but this is a matter for the project manager and technical staff and will not affect the senior management view. Tool Supported. Ideally, the method definition should reside in a tool. This will allow rapid updating of the definition based upon real-world feedback as well as theoretical advances. There is also scope within such a tool for active integration with underlying CASE tools, and automated verification of method integrity. These require rigorous definition of the data involved, both in terms of structure and semantics. To this end a repository is imperative.
The repository is thus a necessity for integration and management of the methods in use. It is also a mechanism to insulate the organization against the turbulence caused by changing techniques and tools. If the underlying information is represented in the repository then:
Repository technology is still immature, but is definitely central to achieving higher levels of productivity and quality. 5. Conclusion Key strategies for managing methods creatively which we can summarise from the foregoing are as follows: Create a stable method environment, preferably incorporating a method model Concentrate effort and attention on the people and management aspects not the technical details For production teams, use tried and proven techniques within a framework that allows rapid evolution of the techniques Have a separate group scan new technologies and plan the evolution of the technical environment Adopt a single comprehensive method definition which is fully integrated and specialise this per project If necessary, acquire methods from various sources, but integrate them under the single framework Don't allow deviations from the method - but adapt the method if necessary. Do this in a controlled way Look for a repository and tools which will assist the above Insist that the method you employ includes quality assurance for every task and deliverable Apply quality assurance principles to the projects and to the use of methods Adopt a consistent management view of projects based upon the Configuration Mangement philosophy Ongoing training is essential in a turbulent environment. We should seek to train to higher levels of skill within the evolutionary framework suggested, rather than periodically re-training the basic skills. Automation of the technical aspects of the lifecycle will allow more time to be focussed on the people and management aspects. Use of a repository should also ease the integration of tools, facilitate sharing and improve quality assurance. Quality & Productivity. It is an established fact that higher skills and better techniques lead to higher quality, and that higher quality leads to increased productivity and reduced risk [41]. These are benefits which we can achieve for our organizations by adopting the approaches suggested here. Bibliography Andersen Consulting. Method/1 Reference, Andersen Consulting, 1990. Andersen Consulting. Plan/1 Product Overview, Andersen Consulting, 1991. D Appleton. A Manufacturing Systems Cookbook Part 2 Datamation, June, 1979. J Arthur. Software quality measurement, Datamation, Dec 15th 1984, 115-120 D E Avison and A T Wood-Harper. Multiview: An Exploration in Information Systems Development, Blackwell Scientific, Oxford, 1990. D E Avison and A T Wood-Harper. Information Systems Development Research: An Exploration of Ideas in Practice, The Computer Journal , 34 (2): 98-112, 1991. R Barker. CASE*METHOD Entity Relationship Modelling, Addison Wesley, 1990. V R Basili and D M Weiss. A Methodology for Collecting Valid Software Engineering Data, IEEE Transactions on Software Engineering, SE10 (6):728-738, Nov 1984. E N Baylin. A Comparitive Review of System Diagramming Methods, Auerbach Publishers, 33-09-20, 1985. B W Boehm, J R Brown, and M Lipow. Quantitative Evaluation of Software Quality, International Conference on Software Engineering, San Francisco, Oct 1976, 592-605. C L Brantley and V R Osajima. Continuing Development of Centrally Developed and Maintained SW Systems, IEEE Computer Society Proceedings, 45:285-288, 1975. E M Brell and A P Sheng. Building Quality and Productivity into a Large Software System, IEEE Software, 47-54, July 1984. D L Burkhard and P V Jenster. Applications of Computer-Aided Software Engineering Tools: Survey Current & Proposed, Database , 28-37, Fall 1989. Butler-Cox. Using System Development Methods, Research Report 57, June 1987. J Campanella and F J Coreoran. Principles of Quality Costs, Quality Progress, 16-22, April 1983. R Canning (Editor). Progress in Software Engineering: Part 1, EDP Analyzer, 16(2), 1978. R Canning (Editor). Developing High Quality Systems Faster, EDP Analyzer, 24 (6), June 1986. R Canning (Editor). Progress in Software Engineering: Part 2, EDP Analyzer, 16 March 1978. R Canning (Editor). The Production of Better Software, EDP Analyzer, 17 February 1979. D N Card , T L Clark and R A Berg. Improving software quality and productivity, Systems, 29(5):235-241, June 1987. P Coad and E Yourdon. Object-Oriented Analysis, Yourdon Press, 1990. Comcon (Pty) Ltd. The GOLD Project Management Methodology, Comcon (Pty) Ltd, 1987. P B Crosby. Quality is Free, McGraw-Hill, 1979. G B Davis and M H Olsen. Management Information Systems: Conceptual Foundations, Structure & Development, 2nd Ed, McGraw-Hill, New York, 1985. T De Marco. Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, 1982. P Duran and A Mc Cready. Structured Analysis and Design: Tools and Methods, Auerbach Publishers 32-01-11, 1984. EDV Studio Ploenzke. Structuring and Specification of System Functions, EDV Studio Ploenzke, 1989. K Ewusi-Mensah and Z H Przasnyski. On Information Systems Project Abandonment: An Exploratory Study of Organizational Practices, MIS Quarterly, March 1991. J V Franch. METHOD/1, Auerbach Publishers 37-1-10, 1987. C Gane. STRADIS, Auerbach Publishers, 37-1-20, 1987. R D Hackathorn and J A Karimi. Framework for Comparing Information Engineering Methods, MIS Quarterley, 203-220, June 1988. IEEE, Standard no 828, Institute for Electronic and Electrical Engineers, 1983. Infomet. The Infomet Methodology, Infomet (Pty) Ltd, 1988. K Jones. Making Effective Use of Modern Development Tools, Butler Cox P>E>P No 10, May 1989. L H Jones and C T Kydd. An Information Processing Framework for Understanding Success & Failure of MIS Methodologies, Information & Management, 15:263-271, 1988. M Langham. Quality Assurance in Systems Development, Butler Cox P>E>P No 9, February 1989. B P Lientz and E B Swanson. Software Maintenance Management, Addison-Wesley, 1980. F Lustman. Managing Computer Projects, Reston Publishing Company, Virginia, 1988. J Martin. Documentation for the October 1990 Seminar, Savant, 1990. S C Mc Intyre and L F Higgins. Object-oriented Systems Analysis and Design: Methodology and Application, 24-35, Date Unknown. G Mc Leod. Achieving I.S. Productivity Through Quality, UCT B Comm (Hons) Essay November 1987. S Murphy, S Harvey and K Mattison. A Status Review of Development Methodologies in South Africa, Empirical Project UCT , November 1990. NCC. SSADM Manual, National Computing Centre, Manchester, U.K., 1986. A Olive. Analysis of Conceptual and Logical Models in Information Systems Design Methodologies, in Trends in Information Systems, 159-181, IFIP, 1986. S Schach. Software Engineering, Irwin, 1990. S L Sullivan and H Hill. Software project stress versus quality and productivity, National Computer Conference, 199-203, 1987. Systematica. Methods Workbench (VSF) Version 3.3 User Manual, Systematica, 1989. D Tajima and T Matsubara. The computer software industry in Japan, Computer, 89-96, May 1981. Tetrarch International. Tetrarch/2 Reference, Tetrarch International, 1985. R H Wallace, J E Stockenberg and R N Charette. A Unified Methodology for Developing Systems, Intertext Publishers McGraw-Hill, 1987. C Wiseman. Strategy and Computers: Information Systems as Competitive Weapons, Dow Jones-Irwin, Illinois, 1985. E Yourdon. Object-Oriented Design, American Programmer, 3(3), March 1990.
|
