Analysis and Design of Information Systems Using OODPM Practical Implementation Offer Drori SHAAM – Information Systems The Hebrew University of Jerusalem E-mail: offerd@cc.huji.ac.il Tel. +972-2-5688439 Fax +972-2-5688681 1. Introduction In the theory of systems, there are many methodologies which are intended to aid in the process of designing information systems or, in other words, to support the maintenance of the life cycle of information systems. One of the methodologies for carrying out the life cycle of the system is OODPM, which combines two existing methodologies: the objects methodology and the prototype methodology. The purpose of this article is to show, in a practical and detailed manner, how to maintain the system life cycle of an information system by using OODPM. It is possible to implement OODPM by means of a word processor on the basis of the framework described in this article and, of course, to use the system dedicated to this: HyperCASE. Key words OODPM, System analysis methodology, Object oriented, Prototype 2. What is OODPM? OODPM, the acronym for Object Oriented Design by Prototype Methodology, is a combination of two known methodologies: the objects approach and the prototypes approach (Drori 1996). Hundreds of articles and books have been written on the objects approach and its use in characterizing business, and other types of, information systems. These include: (Brown 1997), (De Witz 1996), (Kilov & Ross 1994), (Kilov & Harvey 1996), (Kilov 1998), (Kotonya & Sommerville 1997), (Yourdon 1989), (Douglass 1998), and on the prototype approach (Schneider 1996), (Block 1990) (Ribeiro & Bunker 1988). Even though less has been written about it, the prototype approach is no less vital, since it significantly reduces the chance of the failure of an information system, saves many resources and increases user satisfaction. The prototype approach by itself is not free from criticism. Specifically, in many situations in emphasizes premature decision-making since in creating a prototype it is necessary to consider at least some aspects of a possible solution, in addition to formulating the problem itself. Also, screen-orientation in the definition of an activity may be misleading since when the problem is stated its possible solutions using (or not using!) screens ought to be abstracted out; and when a solution of the problem is considered both system specification characteristics and GUI-specific characteristics have to be taken into account. Never the less the advantages of this method for on-line defined system (based on screen user interface) are significant.