Information engineering:Purpose ,Strengths, weaknesses, and limitations

By -

Information engineering

2.1 Purpose

Initially proposed by James Martin and Clive Finkelstein, the purpose of the information engineering methodology is to investigate the data and data relationships among different disciplines, and then organize those data to match the corporation’s goals and objectives. A user-driven system is then developed using a top-down approach.

2.2 Strengths, weaknesses, and limitations

The information engineering methodology relates well to the corporate mission. The analyst is expected to relate all the essential information system components and match those functions to corporate objectives before performing data analysis. The link to the corporation’s goals and objectives adds a high-level, executive, strategic perspective to the methodology. The methodology has a strong data orientation, leading to clearly-defined and documented data and data relationships. It enforces data normalization, which greatly reduces data redundancy and, hence, increases the accuracy and reliability of the database.

Information engineering is not a good candidate for designing real-time systems or systems in which the data have a strong time dimension because the methodology is based on a static data model.

2.3 Inputs and related ideas

The information engineering methodology can be viewed as a special case of the system development life cycle introduced in Chapter 1. Relevant tools are covered in problem analysis paradigms (Chapter 15), systems analysis (Part IV), and component design (Part VI).

2.4 Concepts

The steps in the information engineering methodology are summarized in Figure 2.1.

2.4.1 Strategic requirements analysis

During the strategic requirements analysis stage, the responsible personnel study the corporation’s objectives, access the corporation’s industry and competitive environment, and examine the corporate-wide impact of the proposed system. Key tools and techniques are covered in problem analysis paradigms (Chapter 15) and systems analysis (Part IV).

2.4.2 Information analysis

During the information analysis stage, a data model is created. The analyst begins by analyzing (organizationally and/or functionally) the information gathered during the first stage and further defining the system objectives. Next, the system’s data requirements are defined, the necessary entities, related attributes, and keys are identified, and the appropriate data characteristics (length, type, alias, etc.), structure (name, address, etc.), and relationships are documented in the data dictionary. Given the data dictionary entries, the data are partitioned and normalized. Finally, the results are compared with the predetermined system objectives.

02-01
Figure 2.1  The steps in the information engineering methodology.

Many of the tools and techniques covered in Part IV can be used to perform information analysis, particularly, data flow diagrams (Chapter 24), data dictionary (Chapter 25), entity-relationship models (Chapter 26), and data normalization (Chapter 28).

2.4.3 Procedure formulation

During this stage, the analyst determines the operational procedures (add, delete, update, read, write, etc.) implied by data identified in the previous step. Additionally, physical file attributes (read-only, read-write, etc.) are identified for the subsequent physical database design step.

2.4.4 Data use analysis

During this stage, such data requirements as throughput, turnaround time, file size, and the number of records in each file are defined.

2.4.5 Implementation strategies

Such key decisions as the testing philosophy, hardware and software specifications, development strategy, software make-or-buy decisions, outsourcing/reengineering decisions, and so on are made during this stage.

2.4.6 Distribution analysis

Such factors as the management philosophy (centralized versus distributed), network analysis and design, the need for remote access, and the use of the Internet are considered during this stage. Such tools as network models (Chapter 52) and location connectivity models (Chapter 53) are commonly used.

2.4.7 Physical database design

As the name implies, the database is designed during this stage (Chapter 45). Other major concerns include screen design and output design (Chapters 46 through 51).

2.4.8 Fourth-generation language

The information engineering methodology recommends that non-procedural, fourth-generation languages (CASE generators, screen generators, report generators, object-oriented language, html, Java, etc.) be used to develop the system.

2.4.9 Program specifications synthesis

During the final stage, such details as output specifications (query versus report), the physical relationships among the various files, and the precise structure of the menus (icon, abbreviated, and traditional) are defined.

2.5 Key terms
Data model —
A logical model that emphasizes or is driven by a system’s data.
Data normalization —
A formal technique for designing easy-to-maintain, efficient logical data structures.
Data redundancy —
The state that occurs when the same data are stored in two or more different files.
Fourth-generation language —
A programming language that allows the programmer to describe (in some way) the logical procedure and then let the language translator determine how to implement it; also called a nonprocedural language.
Generator —
A program that starts with information in graphical, narrative, list, or some other logical form and outputs the appropriate source code; also called an application generator, code generator or a program generator.
Information systems strategy —
High-level information system goals and objectives, often derived from or compatible with corporate goals and objectives.
Logical model —
A model that exists on paper or in an analyst’s mind. Logical models are easily manipulated; contrast with physical.
Make-or-buy decision —
A decision to purchase or build internally software (or some other component).
Outsourcing —
Subcontracting work outside the organization.
Physical —
Real; actual, operational hardware, software, or data; contrast with logical.
Procedure —
Guidelines, rules, or instructions for performing a task.
Reengineering —
Rethinking and redesigning business processes.
Throughput —
The amount of work flowing through a process, a component, or a system.
Turnaround time —
The time between a request for a service and the completion of that service.
2.6 Software

Not applicable.

2.7 References
1.  Connor, D., Information System Specification and Design Road Map, Prentice-Hall, Englewood Cliffs, NJ, 1985.
2.  Inmon, W. H., Information Engineering for the Practitioner, Putting Theory Into Practice, Prentice-Hall, Englewood Cliffs, NJ, 1988.
3.  Martin, J., Information Engineering: Introduction, Vol. I, Prentice-Hall, Englewood Cliffs, NJ, 1990.
4.  Martin, J., Information Engineering: Planning and Analysis, Vol. II, Prentice-Hall, Englewood Cliffs, NJ, 1990.
5.  Martin, J., Information Engineering: Design and Construction, Vol. III, Prentice-Hall, Englewood Cliffs, NJ, 1990.
6.  Martin, J., An Information Systems Manifesto, Prentice-Hall, Englewood Cliffs, NJ, 1984.
7.  Martin, J. and Leben, J., Strategic Information Planning Methodologies, Prentice-Hall, Englewood Cliffs, NJ, 1989.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However...
Read more