Software Engineering: A Methodical Approach (2014)
PART G. Appendices
Appendix 3. Object-Oriented Information Engineering
This chapter discusses object-oriented information engineering (OOIE) as the starting point in developing an information infrastructure for the organization. We will start by looking at the organization as a large complex object type, then work downwards into the details. The chapter includes the following sections:
· Introduction
· Engineering the Infrastructure
· Diagramming Techniques
· Enterprise Planning
· Business Area Analysis
· System Design
· System Construction
· Summary and Concluding Remarks
A3.1 Introduction
Software engineering as we know refers to the discipline of specifying, designing, constructing and managing computer software. Information engineering is heavily influenced by software engineering but takes a different perspective: it refers to a set of interrelated disciplines required to build a computerized enterprise based on information systems, and managing the resulting information infrastructure. Information engineering (IE) concerns itself with the planning, construction and management of the entire information infrastructure of the organization. It typically pulls several software engineering projects and other related projects together, and provides general direction to the organization. You might be familiar with the term business process re-engineering (BPR). Information engineering (also referred to as enterprise engineering) includes that concept and much more. Another term that is widely used is OO enterprise modeling (OOEM). As mentioned in appendix 1, for practical reasons, we may consider OOIE and OOEM to be identical, so the rest of the discussion will stick with OOIE.
The following are some broad objectives of IE:
· Support of the management needs of the organization
· Aligning the information infrastructure to the corporate goals of the organization
· Increasing the value and credibility of the computerized systems
· Effective management of the information so that it is available whenever required
· Increasing the speed and ease of software application development
· Reducing the rigors of software systems maintenance
· Achievement of integration of component systems
· Facilitation and promotion of reusable design and code
· Promotion of a higher level of communication and understanding between IS professionals and non-IS professionals in the organization
Desirable characteristics of IE include the following:
· It involves higher user participation.
· It involves the use of sophisticated software planning and development tools (CASE tools, DBMS suites and RAD tools).
· It embraces CBSE through integration of component systems.
· It leads to an organization that is more progressive, efficient and technologically aware.
A3.2 Engineering the Infrastructure
In planning an organization’s information infrastructure, the following three important ingredients must be considered:
· The structure of the system’s required object types
· The behavior of the required system operations
· The underlying technology required to support the organization’s mission and operations
James Martin’s information system (IS) pyramid (see [Martin, 1989a] and [Martin, 1993]) proposes four levels of planning that address these ingredients:
· Enterprise Planning
· Business Area Analysis
· System Design
· System Construction
According to Martin, these four strands of information management must relate to the three sides of the pyramid — relating to structure, operations, and technology. These concepts are summarized in Figure A3-1. Upcoming sections of this chapter will discuss each strand of information management, but first, a discussion of diagramming techniques is in order.
Figure A3-1. Overview of Martin’s IS Pyramid
A3.3 Diagramming Techniques
If you are going to make any significant progress in designing the information infrastructure, you will first need to put together a number of technical documents. Covering large volumes of information in a succinct, comprehensive manner is critical; hence the importance of diagrams.
Figure A3-2 provides a list of recommended diagramming techniques that are applicable to OOSE. Most of these techniques have been discussed or mentioned in the course. In the interest of additional clarity, some of them will be revisited, and the new ones discussed in the upcoming sections of this and subsequent chapters of the appendices. There are other diagramming techniques that are used in OOSE, but these are the ones that this course recommends. At the highest level of planning the information infrastructure of a business enterprise, or architecture of a software system, object flow diagrams and information topology charts are useful. From this point, you then proceed down into the structure of the various object types that comprise the system. Then you address the behavior of instances of each object type.
Figure A3-2. Recommended OOM Diagramming Techniques
A3.4 Enterprise Planning
A full discussion of enterprise planning is beyond the scope of this course; however, in the interest of comprehensive coverage, a brief summary is provided here. In the broadest sense, enterprise planning relates to planning the essentials of the organization. In OOIE, we concentrate on issues that relate (directly or indirectly) to the information infrastructure of the organization. As such, enterprise planning involves a number of important activities, including the following:
· Planning the information infrastructure of the organization
· Managing that infrastructure in the face of changing user requirements, changing technology, challenges from competitors, etc.
· Planning and pursuing appropriate IT strategies for the organization
· Having a proper backup and recovery policy
· Human and technical resource management
· Project management
Of course, each of these activities involves has its own set of principles and methodologies. Three very useful diagramming techniques here are the information topology chart (ITC), the user interface topology chart (UITC), and the object flow diagram (ODF). Figure A3-3 illustrates a partial ITC for the CUAIS project; Figure A3-4 illustrates a partial UITC for the project; and Figure A3-5 shows an OFD for the project.
Figure A3-3. Partial Information Topology Chart for the CUAIS Project
Figure A3-4. Partial UITC for the CUAIS Project
Figure A3-5. OFD for the CUAIS Project, Assuming Repository Model
A3.5 Business Area Analysis
In business area analysis (BAA), we are interested in the nature of participation that each business area of the organization will have (or already has) on the component systems comprising the information infrastructure. In particular the information system executive wants to ensure the following:
· The underlying object (database) structure must meet the needs of various business areas.
· The operations provided must meet the requirements of the various business areas.
· Appropriate security mechanism must be put in place to ensure the resources (objects and operations) of the integrated system are accessible to the relevant functional areas of the organization.
Typically, diagrams and/or matrices are constructed to reflect critical information:
· Object structure diagrams indicate the structure and operational services of information object types (in case of object oriented (OO) approach). Alternately, you may use object/entity specification grids (O/ESGs). Figure A3-6 provides an illustration of O/ESG for four of the object types (or entities) that would comprise a typical manufacturing firm’s database. In actuality, there would be one for each object type (or entity) comprising the system.
Figure A3-6. Partial O/ESG for Manufacturing Environment
· Object-operation matrices show how various object types will be used in different business areas.
· System-component-business-area matrices show what functional areas will use certain system components of the information system, and how.
In constructing the matrices for the BAA, always cluster related components (object types or sub-systems) together. Figure A3-7 illustrates an object-operation matrix while Figure A3-8 illustrates a component-business-area matrix.
Figure A3-7. Object-Operation Matrix for a Financial Management System
Figure A3-8. Component-Business-Area Matrix for a University
A3.6 System Design
System design relates to design of the component systems that comprise the information infrastructure of the organization. To be excellent at designing information infrastructures, you need to have mastery of software engineering, database systems, and an understanding of how a typical business works. You also need to have a working knowledge of programming, and outstanding communication and leadership skills. You also need to have mastery of various software diagramming techniques, many of which have been covered in the course. Figure A3-9 provides a checklist of design issues with which you should be familiar (review chapters 9 – 13).
Figure A3-9. Summary of System Design Considerations
Following are some basic guidelines that should guide the design process:
· The design must be accurate and comprehensive, covering both structure and behavior of system components, and with due consideration to the availability of technology.
· The design must adequately take care of current and future requirements of the (component systems in the) organization.
· The design must be pragmatic.
· The design must be informed by the software quality factors emphasized throughout the course (review chapters 1 and 3).
· The design must uphold established software engineering standards.
A3.7 System Construction
System construction relates to the development of the component systems that comprise the information infrastructure of the organization. If enterprise planning, business area analysis and system design were accurate and comprehensive, system construction will simply be the implementation of a carefully developed plan. You will recall from your knowledge of software engineering, that system acquisition may take any of several alternatives. Figure A3-10 summarizes these alternatives.
Figure A3-10. Software Acquisition Alternatives
Finally, please remember the following points:
1. Software system design and construction must conform to established software development standards.
2. Software acquisition must follow a clearly developed plan with specific targets (deadlines).
3. Prudent project management will be required if targets are to be met.
A3.8 Summary and Concluding Remarks
Let us summarize what we have covered in this chapter:
· Information engineering (IE) is the planning, construction and management of the entire information infrastructure of the organization. Object-oriented information engineering (OOIE) is IE conducted in an object-oriented manner.
· OOIE may be conducted by pursuing four steps: enterprise planning, business area analysis, system design, and system construction.
· Enterprise planning relates to planning the essentials of the organization. In OOIE, we concentrate on issues that relate (directly or indirectly) to the information infrastructure of the organization.
· In business area analysis (BAA), we are interested in the nature of participation that each business area (of the organization) will have (or already has) on the component systems (and system components).
· System design relates to design of the component systems that comprise the information infrastructure of the organization.
· System construction relates to the development of the component systems that comprise the information infrastructure of the organization.
· In conducting OOIE, there must be mastery and appropriate use of various diagramming techniques that are applicable to OOSE.
Since its introduction, information engineering has been overtaken by (or more precisely, morphed into) methodologies such as data administration, and business intelligence (see [Turban, 2007] and [Turban, 2008]). However, the principles of IE are still relevant. When OOIE is combined with life cycle models such as phased prototyping, iterative development, agile development, or CBSE, you have formula for successful software engineering.
Once you have obtained a good overview of the information infrastructure of the enterprise, your next step is to zoom in on each component system and provide more detail in terms of the structure and behavior of constituent objects comprising the system. The next chapter will address the relevant issues relating to this.
A3.9 References and/or Recommended Reading
[Martin, 1989a] Martin, James and James Odell. Information Engineering Book I: Introduction. Eaglewood Cliffs, New Jersey: Pretence Hall, 1989.
[Martin, 1989b] Martin, James and Joe Leben. Strategic Information Planning Methodologies. 2nd ed. Eaglewood Cliffs, New Jersey: Pretence Hall, 1989. See chapters 2 and 13.
[Martin, 1990a] Martin, James and James Odell. Information Engineering Book II: Planning and Analysis. Eaglewood Cliffs, New Jersey: Pretence Hall, 1990.
[Martin, 1990b] Martin, James and James Odell. Information Engineering Book III: Design and Construction. Eaglewood Cliffs, New Jersey: Pretence Hall, 1990.
[Martin, 1993] Martin, James and James Odell. Principles of Object Oriented Analysis and Design. Eaglewood Cliffs, New Jersey: Pretence Hall, 1993. See chapter 5.
[Sprague, 1993] Sprague, Ralph H. and Barbara C. McNurlin Information Systems Management in Practice. 3ed Eaglewood Cliffs, New Jersey: Pretence Hall, 1993. See chapters 4.
[Turban, 2007] Turban, Efraim, Jay Aaronson, Ting-peng Liang, and Ramesh Sharda. Decision Support and Business Intelligence. Eaglewood Cliffs, New Jersey: Pretence Hall, 2007.
[Turban, 2008] Turban, Efraim, Ramesh Sharda, Jay Aaronson, and David King. Business Intelligence. Eaglewood Cliffs, New Jersey: Pretence Hall, 2008.