PRIDE ® -ISEM
Information Systems Engineering Methodology
An integral part of Information Resource Management (IRM)
PHASES:   1   2   3   4-I   4-II   5   6   7   8   9
SUPPORT   FORMS

TRANSLATE THIS PAGE TO... Chinese (simple)   Japanese       Dutch   French     German     Italian    
Free Translation courtesy of ALS      Chinese (traditional)   Korean       Portuguese       Russian       Spanish         

CONTENTS

"An information system is a product that can be engineered and manufactured like any other product."
- Bryce's Law

This section contains the following:

 
    BUSINESS PURPOSE

    The "PRIDE"-Information Systems Engineering Methodology (ISEM) is an important part of an overall philosophy of Information Resource Management (IRM) as defined by "PRIDE". This involves the development and control over all of the resources required to produce information. Whereas the "PRIDE"-Enterprise Engineering Methodology (EEM) is principally concerned with developing an Enterprise Information Strategy, methodologies such as ISEM and the "PRIDE"-Data Base Engineering Methodology (DBEM) are concerned with actually building the system and data resources needed to produce information.

    The intent of any of the "PRIDE" methodologies, including ISEM, is to define the business environment as to "Who" is to perform "What," "When," "Where" and "Why" (the "5W's"). As a result, it is used to convert a heterogeneous operating environment into a homogeneous environment. This improves communications and promotes cooperation and teamwork throughout an enterprise. Better organization and discipline also enhances the ability to build quality products and make effective use of resources. In addition, to the 5W's, the methodology provides "How" to perform the work by providing a variety of techniques and tools that are deployed throughout the methodology. A methodology, therefore, resembles an assembly line where work is performed in manageable stages.

    ISEM is a generic and universally applicable approach for building any type of information system, regardless of industry, type of application, or software language/technique. It is based on tried and proven approaches that are so fundamental to sound system design that tailoring to individual development requirements is not only unnecessary but highly undesirable. It has been used around the world to develop applications in every field of endeavor imaginable, including banking, communications, education, government, insurance, manufacturing, retail, transportation, utilities, etc.

    ISEM is concerned with building major systems in their entirety; this includes integrated business processes, complete with administrative and computer processing. As such, ISEM provides the high-level systems architecture required by software engineering to develop computer programs. Because of this, software engineering is considered a subset of ISEM. Although ISEM provides the ability to design any type of system, it does not mandate the use of any particular programming language or design technique. Consequently, the programming phases of ISEM (4-II, 5 and 6) allow for the use of any pertinent software engineering tool or technique.  

    CONCEPTS & PHILOSOPHIES

    "It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who would gain by the new ones."
    - Machiavelli, "The Prince" (1513)      

    INFORMATION = DATA + PROCESSING

    The processing of data is surely as important as the data to be processed. Whereas the data represents "what" is to be processed, processing (or systems) represents "how" it is to be processed, using formulas, algorithms or calculations. An invalid calculation is just as misleading as invalid data; both will produce erroneous information. From this perspective, both data and processing must be carefully designed and controlled as resources for producing information. Whereas Data Base Engineering is concerned with the integrity of the data, Information Systems Engineering is concerned with the integrity of systems.

    An information system is not an amorphous mass. It has specific characteristics that can be precisely defined. For example:

    • It has a purpose; to produce information to serve business needs.

    • It operates routinely in a predictable manner. In fact, it runs in time frames required to make specific decisions and take actions.

    • It is a grouping of one or more elements which form a whole; this defines the scope of the system.

    These three characteristics represent the basic elements of any system, information or otherwise.

    With the advent of the computer many in the field have come to regard an information system as nothing more than a collection of programs or "jobs." From this perspective, there is little consideration for processing through non-computer means. As a result, non-computer processing and data are treated as irrelevant, and users are left with the awkward task of synchronizing administrative processing with computer processing.

    Those biased with programming suffer from a narrow perspective of the system. Anything outside of computer software and hardware is considered meaningless. This is one of the primary reasons why information systems lack integration; some developers tend to ignore the overall picture and concentrate only on the computer. Many developers are more concerned with programming than they are with engineering the overall system. The analogy here is that there are many carpenters on the job, but very few architects. This is why systems development is usually regarded as an art rather than a science.  

    A SYSTEM IS A PRODUCT

    The fact of the matter is, an information system is a product that can be engineered and manufactured like any other product. With a product orientation, a system consists of several levels of abstraction, from general to specific, that define the processing.

    Information System - Represents the highest level of the product and the scope of the system. An information system is arbitrarily defined by an organization; it is based on the total number of sub-systems that an organization desires to satisfy business needs. It is possible for a company to operate with a single system consisting of hundreds of sub-systems. It is also conceivable to have several systems. It ultimately depends on how the organization perceives the system. In any case, an information system is defined as one or more sub-systems that satisfy information requirements in particular time frames.

    Sub-Systems - Represents a business process that exists within a unique time frame. It is a logical process that dictates "what" data is to be processed and "when." Each sub-system consists of one or more administrative procedures and one or no computer procedures. As an example, a payroll application may have the following sub-systems:

    • Daily time posting by non-exempt employees.
    • Weekly time posting by exempt employees.
    • Payroll/Employee adjustments.
    • Query employee time history.
    • Weekly paychecks for non-exempt employees.
    • Monthly paychecks for exempt employees.
    • Monthly government reporting.
    • Quarterly government reporting.
    • Year end government reporting.

    Administrative Procedures - Physically defines "who" is to perform "what" operations from an administrative perspective, e.g., manual processing, office automation processing, data entry, etc. The administrative procedure consists of one or more operational steps.

    Operational Steps - Represent specific actions to be performed or decisions made.

    Computer Procedure - Like the administrative procedure, this procedure defines "what" operations the computer will perform. The computer procedure consists of one or more programs.

    Programs - These are comparable to the operational steps of the Administrative Procedure. Programs represent executable tasks to be performed by the computer.

    There is little difference between an administrative procedure and a computer procedure; the only difference is the "actor" who has to perform the work. Whereas administrative procedures will deal with manual and non-computer processing, the computer procedure deals with computer processing. Of the two types of procedures, administrative procedures are the most commonly overlooked and omitted. Systems fail more for the lack of administrative procedures than they will for well written computer procedures. If people do not know how to use the systems, the systems will not be used.

    This product structure provides the architectural framework required to engineer an information system. All information systems, that function, have this structure. In manufacturing terms, it can be described as a "four-level bill of materials" which shows the product from the general to the specific. Any information system can be modeled using this standard system structure. Omission of any of these resources will highlight problem areas in a system.

    STANDARD SYSTEM STRUCTURE

    A System is a Product

    During system design, the product structure is decomposed or "exploded" downward until the smallest elements are defined. The product structure is then "imploded" upward during testing and implementation. This "explosion/implosion" technique is common to engineering/manufacturing.  

    SYSTEMS INTEGRATION

    The only way systems communicate, internally or externally to other systems, is through data. It is the only way that a system interfaces with other systems, a sub-system to other sub-systems, an administrative procedure to a computer procedure, program to program; through data. Data represents the adhesive element that holds systems together. It should be defined and standardized so it can be re-used in as many applications that require it. However, because many people in the field view systems as nothing more than isolated programs, they feel it is more convenient to define data on an application-by-application basis. This is the primary reason for data redundancy.

    Under the engineering/manufacturing philosophy, data is treated as a "materials management" issue where it is standardized and controlled for maximum efficiency and cost effectiveness. This scenario calls for data to be defined in the same manner as a part to a product: it is classified, inventoried and re-used. Data base, therefore, is treated as a management issue concerned with controlling all of the data required to produce information, regardless of where used or how stored. It is not a technical problem that is concerned only with data physically stored on the computer and managed by a DBMS.  

    INFORMATION DRIVEN DESIGN

    Since the intent of an information system is to produce information, the more we understand about information, the better we can accommodate its implementation. This is why we refer to this concept as "Information Driven Design," a system design based on the characteristics of information.

    INFORMATION DRIVEN DESIGN CONCEPT

    Information is used to support specific actions and/or decisions of the business. There are actually three types of information:

    • Policy Information - To implement executive decisions.

    • Control Information - To monitor policy and manage operations.

    • Operational Information - To implement the routine day-to-day activities of the business.

    Information is a dynamic and perishable commodity. It only has value at the time it is required. Whereas the definition of data is constant, information requirements can change for a variety of reasons, such as politics, government, competition, economics, people, etc. Ultimately, corporate survival depends on providing the users with accurate and timely information.  

    TIMING

    In order to properly specify information requirements, it is not sufficient to merely determine what data is necessary; it is also necessary to define the timing of the information. This timing will ultimately dictate how data will be collected, stored, and retrieved to produce information.

    Failure to recognize timing as an important element of design will result in the data base being out of synchronization with the application. For example, consider a situation where data is collected on a routine weekly basis. Daily analysis of the data will be inappropriate since the data will remain constant until the next weekly update. To resolve the conflict, data collection should be changed to daily basis.

    All information systems operate in time frames, such as instantaneous, daily, weekly, monthly, quarterly, etc. If this is true, why not make use of this timing consideration during system design as opposed to discovering it afterwards while trying to correct the data base design?

    There are three aspects to timing: frequency, offset and response time.

    • FREQUENCY defines "how often" the information is required, e.g., upon request, hourly, twice daily, once a week, monthly, quarterly, semi-annually, etc.

    • OFFSET defines when processing should begin, such as the beginning of the week, end of the month, etc. However, if the frequency is 'upon request,' then there is no scheduled offset; this is because the information can be requested at any point in time.

    • RESPONSE TIME defines how fast the information must be delivered to the user. For example, five seconds, two hours, one day, etc. This should not be confused with computer 'response time' or 'throughput' which is concerned with machine speed. Rather, response time is concerned with the maximum amount of time that will transpire between the request and delivery of the information, so the user can make the necessary decisions and/or take action. This implies that if the response time is exceeded, it is no longer information, only historical data.

    The data required to produce information must be defined in terms of what primary data must be supplied externally to the system by a user, and what generated data must be calculated internal to the system. Data relationships can be extensive. For example, the data element "Net Pay" may be based on a complicated computation:

    NET PAY = GROSS PAY - FICA - CITY TAX - UNION DUES - (ETC.)

    Other data elements used in the formula may also be generated, such as:

    GROSS PAY = HOURS WORKED X PAY RATE

    What this means is that in order to arrive at the correct value for "Net Pay," we must be able to reach all of the primary values, such as "Hours Worked" and "Pay Rate," in a timely manner. If we cannot do this, "Net Pay" will be incorrect.

    Defining these data dependencies has typically defaulted to the programmer who redefines the relationships with each application and buries it in the program source code, making maintenance and change considerably difficult. (It is not unusual to find "Net Pay" defined differently in multiple applications throughout a company.)

    The basic operations that can be performed on data include "create," "update" and "reference" ("delete" is the opposite of "create"). In programming terminology, a "create" represents a "write," an "update" represents a "read/write," and a "reference" represents a "read" only.

    The timing and data specifications resulting from the information requirements will ultimately dictate the type of system to be created. For example, if information is needed upon request and within a matter of seconds, this will probably result in an "interactive" type of process. However, if the information is required upon request but within a few hours, this will probably result in "batch" type processing (it may even be processable manually). These specifications are the basic building blocks for all systems and software design.

    Producing an information system design that correctly satisfies requirements is a vital part of information driven design. The resulting system will only be as good as the specifications from which it is based. With this approach, the emphasis is on business analysis as opposed to technical detail. No amount of elegant programming or technology will solve a problem if it is not defined or understood correctly.  

    CHRONOLOGICAL DECOMPOSITION

    This is the technique used to implement the concept of "Information Driven Design." As the name indicates, timing is an essential part of chronological decomposition. Based on information requirements, chronological decomposition breaks a system into its logical business processes (sub-systems) based on timing with their specific inputs, outputs and files. It synchronizes all of the data required to support the system into an application logical data base.

    Essentially, the technique works backwards, from the receiver of the information, to the source of the primary data; from outputs to inputs. In this way, it forces the systems engineer to consider all of the data required for the application. This eliminates the problem of forgetting required data. It also emphasizes the need for sharing data. As a design develops, consideration is given to using data from other applications. After all, why create new files and processes if they already exist in the data base?

    Perhaps the most significant benefits derived from chronological decomposition, as reported by users, is that it organizes the data and simplifies processing.

    With the logical design defined, consideration is then given to the most appropriate way to physically process the data, either manually or computer assisted. This is where the "work flow" is designed, from start to end; from input to output. Here is where functional decomposition and data driven design excels. For software engineering, the characteristics of the data, its structures and what functions the computer must perform (e.g., create, update and reference) dictates the required programs. These specifications are the result of chronological decomposition. The physical characteristics of the data defines its validity. The data structures denote input, file and output relationships. The functional requirements determine how the data will be read and written in a program, whether sequentially, iteratively or selectively.

    In no way should chronological decomposition be confused with functional decomposition. Both have distinctly different purposes and objectives. Whereas the former is concerned with logical system design based on the characteristics of information, the latter is concerned with how data is to be processed physically. They are not conflicting techniques. In fact, they are complementary as long as they are placed in the proper perspective. To try to use one in place of the other is unproductive. They simply have entirely different roles.

    CHRONO.BMP  

    METHODS OF PROCESSING

    Regardless of the jargon of the day, all processing is based on "transactions," whether it is to request an output or to collect data. Buzzwords like "on-line," "real-time," "interactive," and "batch" only cloud the issue.

    A transaction represents some form of operation. For output reporting, "request," "display," "print," "extract," "search," etc. are common transactions. For input, "new," "add," "change," "delete," "update," "charge," "credit," "debit," "deposit," etc. are typical transactions.

    Transactions can be processed either one at a time (as in "interactive") or in groups ("batch"). What is then important is the volume of transactions and the speed they must be processed (as specified by timing). This will determine the physical constraints of the equipment to be used. "Batch" processing has the advantage of processing high volumes of transactions within a relatively short period of time per transaction. "Interactive" processing has the advantage of processing individual transactions quickly.

    The tendency to be more concerned with the techniques of processing than with the problems to be solved can cause systems to be physically implemented in ways resulting in high operating costs. The governing issues should be, "What is the business problem to be solved?" and, "How effective is the processing method concerning the value and timing of the information to be produced?" Programming techniques have little value in these areas. Consider, for example, that batch processing will always be a viable solution for information systems design regardless of the direction technology moves. This method of processing is analogous to many manufacturing operations where products are more economically manufactured in groups or batches - as opposed to one at a time. The point is, this situation will always be true regardless of how close the costs become between the two methods. For example, can you imagine preparing the corporate payroll interactively (one check at a time)? Technology should implement the logical business solutions to the problem and not be a platform to display technical elegance.  

    FORMS OF PROCESSING

    In any processing, computer or otherwise, there are three basic forms of processing that can be used: sequence, iteration, and choice.

    SEQUENCE - This type of processing represents a continuous series of steps, for example:

    ITERATION - Represents repetition until a certain condition is met, for example:

    CHOICE - Permits the selection of processing paths based on prescribed criteria. It also allows for parallelism; for example:

    Obviously, these processing constructs can be combined in many different ways to process data. All procedures, programs, and steps consist of combinations of these constructs.

    Again, timing has a role to play here. Frequency, offset, and response time are used to synchronize processing. It dictates how often processing must occur, when each process is to start, and how fast it must process data. Without timing, processing will be awkward and cumbersome to perform.  

    LAYERED DOCUMENTATION

    Whereas system design moves a system from logical specifications to ultimate physical implementation, documentation, which is a reflection of the design, should do likewise. Documentation is a working tool and a by-product of design. This is comparable to blueprinting, where a product is designed to various levels of detail, from the general to the specific. In addition to being used as a tool to refine designs, this "layered" approach to documentation is used to communicate the various levels of abstraction to users and designers.

   

    The major deliverables resulting from the design phases of ISEM include:

    1. System Study & Evaluation Report (Phase 1) - This manual represents the "feasibility study" where information requirements are defined and a proposed system solution developed. An information flow diagram and system concept diagram are included in this manual.

    2. System Design Manual (Phase 2) - This manual defines the specifications for all of the sub-systems in the application. A system flowchart is maintained in this manual which depicts the sub-systems within the system.

    3. Sub-System Design Manual (Phase 3) - This manual defines the specifications for the procedures in a single sub-system. This includes a sub-system flowchart showing the procedures within the sub-system.

    4. Administrative Procedure Manual (Phase 4-I) - This manual defines the specifications of the operational steps in the procedure. This represents the manual used by end-users when operating the system. Unlike the computer procedure flowchart that shows programs, the administrative procedure is written using "playscript," a manual procedure language developed by Les Matthies. "Playscript" is based on a script to a play, with "actors" and "actions."

    5. Computer Run Book (Phase 4-II) - This manual defines the specifications for the programs in a computer procedure. This is where a computer procedure flowchart is maintained showing the programs within the procedure. In addition to being used for program design, this manual will become the documentation used by computer operations personnel. For each program, a Software Structure Diagram will be prepared expressing the internal processing logic.

    This "blueprinting" approach to documentation shows how it is used as a working tool during design. As modifications are made to the system, the appropriate level in the documentation incorporates the changes. This simplifies maintaining documentation and keeps it current with the system. In addition to flowcharts and supporting narratives, test requirements are incorporated into the documentation for use during the testing and implementation phases of ISEM.  

    GRAPHICS

    The basic types of graphics associated with ISEM include:

    Information Flow Diagram (IFD) - This diagram illustrates how information is used by an enterprise for a single system. It defines the boundaries of the system as to who originates, receives and participates in the flow of information in an application. NOTE: The IFD should not be confused with "Data Flow Diagrams" as used in programming.

    INFORMATION FLOW DIAGRAM

    The IFD can also be drawn with Functional Entities (FE)

    The System Concept Diagram provides a free-form schematic of the overall system. Like an architect's "rendering," this diagram is used to paint a picture for the user to easily visualize the end product. Like the Information Flow Diagram, it denotes the boundaries of the application.

    SYSTEM CONCEPT DIAGRAM
    Free-Form Schematic

    The System Flowchart shows the second level of detail in the system hierarchy: sub-systems. Each sub-system is drawn with its inputs, outputs, files and timing. A Table of Files section at the end of the flowchart shows how all of the files in the application are used by the various sub-systems (create/update/reference).

    SYSTEM FLOWCHART
    Uses ANSII Standard Symbols

    ARROWS INDICATE DIRECTIONAL PROCESSING FLOW (LEFT-TO-RIGHT)
    GRAPHIC RELATES TO SUB-SYSTEM NARRATIVE

    The Sub-System Concept Diagram is a free-form schematic illustrating the general processing flow in a sub-system. It is drawn in a similar manner as the System Concept Diagram.

    SUB-SYSTEM CONCEPT DIAGRAM
    Free-Form Schematic

    Used to describe the physical processing of the sub-system

    The Sub-System Flowchart shows the third level of detail in the system hierarchy: procedures - both administrative and computer. This type of flowchart represents a "process diagram" showing the flow of work in the sub-system. The precedent relationships between procedures are drawn which specify sequence, iteration and choice. In addition, the use of inputs, outputs and files show how data flows throughout the procedures.

   

    The Computer Procedure Flowchart shows the fourth level of detail in the system hierarchy: programs. It is drawn in a similar manner to the sub-system flowchart. Processing logic, inputs, outputs and files are all shown.

   

    A Software Structure Diagram is used to graphically represent the processing logic either within a single program or a module. This type of diagram is based on the software engineering technique used which may vary from program to program.

   

    Each graphic is supported by narrative describing the processing logic for each level of detail.

    This approach to documentation highlights the fact that system documentation can and should be completed prior to programming, not afterward. Graphics, processing logic, testing criteria, user instructions, input/output/file layouts, messages, etc. can all be prepared prior to the actual coding of the program. It all depends on whether design and documentation is viewed in the same vein as the approach used in architecture or engineering. Why should systems development be any different?

    For additional information on "PRIDE" Graphics, see: "PRIDE" Flowcharting Symbols.  

    SOFTWARE ENGINEERING

    From the perspective that computer procedures and programs represent only a portion of the information system architecture, software engineering is viewed as a subset of information systems engineering. Although programming ultimately represents nothing more than the translation of specifications into machine processable instructions, the intent of software engineering goes beyond this. It is concerned with developing computer software that is reliable, easy to maintain and modify, and performs in an efficient/cost effective manner.

    Software exhibits some very "hard" characteristics. For example, it is typically not portable across computers. If software was truly portable, there would not be the many different "versions" of the same software product to suit different operating systems. Because of this, software engineering represents more physical design as opposed to the logical design of systems engineering.

    The most important part of software engineering is in the architectural design and development of the computer procedure. The actual coding is merely a translation process, not unlike going from English to some other language. When the specifications for the procedure are developed, usually in a human understandable language, it is the programmer's responsibility to code or translate this into a language the computer understands. All the coder needs to know is the language, conventions, and the computer environment. This process is relatively simple and borders on being administrative which means that it can be automated.

    Good systems engineering specifications will improve programmer productivity far better than any programming tool or technique. If good systems engineering specifications are prepared and software engineering practices are properly applied, then productivity will be maximized.

    As we have seen, systems engineering is based on simple, straightforward, and commonly known principles. Some might say it is a discipline that stifles creativity. This is like saying that architecture, engineering, even music, lacks creativity, for these are all disciplines based on some form of science. There is science in every art, and an art to every science. Information systems engineering is a science; a teachable science.  

    METHODOLOGY CONSTRUCTION/NAVIGATION

    The Information Systems Engineering Methodology (ISEM) consists of an assembly of nine phases detailing what is to be accomplished and by whom. Each phase consists of a defined set of activities (a total of 41); each activity consists of a series of operations or tasks to be performed. All phases, activities and tasks produce tangible deliverables that can be reviewed and checked. These deliverables substantiate adherence to the methodology and permits the measurement of progress. Both formal and informal review points are laced throughout the methodology which provides for an effective dialog between management, users, and systems developers.

    The first phase is essentially used to plan the ISEM project. The remaining phases map the system structure as mentioned earlier. Phases 2, 3 and 4 are used to "explode" or decompose the system into its smallest pieces. The remaining phases are used to "implode" the structure through testing and implementation. The final phase (9) is used to evaluate the ISEM project.

    METHODOLOGY CONSTRUCTION

    By carefully modularizing the work effort, phases can be conducted in parallel and concurrently, a much more effective way of utilizing resources than the linear approach found in the classic "five-step" project management oriented methodology (feasibility, design, program, test, review). This is the difference between an engineering approach versus an administrative one.

   

"PRIDE-ISEM
Information Systems Engineering Methodology
Methodology Concept Diagram

    PHASE 1 - "System Study & Evaluation"

    Phase 1 is used to identify the system(s) involved. It represents the feasibility study phase where current systems are analyzed, information requirements specified, and an overall system solution is proposed. The solution is represented by a complete rough design of the system, covering all levels, including programming. This becomes the basis for considering alternative solutions, including third party software available for purchase.

    From the rough design, an estimate and schedule for the whole project can be developed along with a cost/benefit analysis. This is used by management to make project decisions, such as continuing, discontinuing or revising the project. Architects and engineers use a similar approach when proposing a new building or product.

    The Information Flow Diagram and System Concept Diagram are prepared during this phase and included in the "System Study & Evaluation Report," the formal deliverable resulting from Phase 1.

    Following this phase, the project proceeds to Phase 2. If more than one system has been identified in Phase 1, separate Phase 2's will be required. In this event, it is usually desirable to divide the project into separate projects to simplify design and management. This results in one project for each system identified.

    PHASE 2 - "System Design"

    This phase represents the formal definition of the sub-systems within the system. Using chronological decomposition, sub-systems are defined into unique time frames, along with their inputs, outputs and files.

    Complete illustrative examples of the reports and screens are prepared for review by users. Prototyping tools can be used in the preparation of physical screens and reports. It should be emphasized that prototyping tools are not a substitute for determining information requirements, nor the logical design which must be performed prior to prototyping. Prototyping can only create a working model of the system as logically designed. It is used to "fine tune" the physical implementation.

    The System Flowchart and Sub-System Concept Diagrams are prepared during this phase and is included in the "Systems Design Manual," the formal phase deliverable.

    Based on the system design, the project scope is updated along with the project estimates and schedules. This is then reviewed with management to determine whether the project should be continued, discontinued, or revised.

    Following Phase 2, a Phase 3 will be executed for each sub-system identified in the System Design. There is a one-to-one relationship between Phase 3 and a sub-system. If there are multiple sub-systems, there will be multiple Phase 3's which may be conducted in parallel or executed sequentially. This, of course, is a matter of available resources and schedule commitments. At this point, some organizations assign project leaders to each sub-system since they can be implemented independent of each other.

    PHASE 3 - "Sub-System Design"

    The logical sub-system is decomposed into physical procedures to process the data, both administrative and, where pertinent, computer. Design is based on efficiency and cost effectiveness. From this perspective, it represents the Industrial Engineering phase of the methodology.

    The sub-system flowchart is prepared and included in the "Sub-System Design Manual," the formal deliverable from this phase.

    Project estimates and schedules are revised as required, but only as they pertain to the delivery of this sub-system.

    Phase 3 represents the last major review for management. It will be followed by Phase 4-I for Administrative Procedure Design and Phase 4-II for Computer Procedure Design, both of which can be conducted in parallel.

    PHASE 4-I - "Administrative Procedure Design"

    During this phase, the operational steps for each administrative procedure in the sub-system are defined. The "playscript" procedure language is used to write the steps.

    The written procedures are then packaged with samples of the inputs and outputs into an "Administrative Procedure Manual" for review by the end user. This manual represents the formal deliverable from the phase and will be used by the users of the system when installed.

    PHASE 4-II - "Software Engineering"

    This phase represents the point in the methodology where software design formally begins in the methodology. Although programming is consulted during the earlier phases, Phases 4-II, 5 and 6 represents their primary area of work. Whereas system engineering is preparing the administrative procedures for the sub-systems, the programmers now begin to concentrate on the design and development of the computer procedure and programs.

    During Phase 4-II, a software implementation strategy is formed and programs defined. This includes, what inputs, outputs and files they will use, the processing logic for each program, including the processing flow to other programs, the control language statements (e.g., JCL, DCL, ECL, etc.) to be used, and the selected programming language, whether procedural or non-procedural (e.g., 4GL).

    The logical files defined in the earlier phases are converted into physical files for use in the application by Data Base Administration. File layouts for use in programming are provided at this point, regardless of whether a DBMS is used.

    A Computer Procedure Flowchart is prepared, along with pertinent Software Structure Diagrams, and included in the "Computer Run Book," the formal deliverable from the phase. This manual will be used by computer operations later and by programming in Phase 5.

    A technical review is performed at the end of the phase, with computer operations assuming the role of the user.

    Following Phase 4-II, a Phase 5 will be executed for each program identified in the Computer Procedure. This means that programs can be designed in parallel.

    The remaining phases are used to "implode" or manufacture the system structure during implementation:

    PHASE 5 - "Software Manufacturing"

    Before Phase 5 begins, the program has been fully specified. So much so, that a program generator, report writer or 4GL should be able to interpret these specifications and produce the program automatically. In the absence of these devices, the program must be written manually.

    If a procedural language is used, such as COBOL, the programmer should only have to produce the procedure division of the program. All other aspects should have been provided.

    The intent of the phase is to produce a program, either manually or automatically, and perform a unit test of it. Test data is prepared and results collected. Testing should be performed in accordance with the test criteria as established in the Computer Run Book. Obviously, test data generators are useful for testing.

    PHASE 6 - "Software Testing"

    This phase is concerned with performing a "string" test of all of the programs within a specific computer procedure.

    Although each program was individually tested in Phase 5, they are now brought together and tested as a whole. Again, testing should be performed in accordance with the specifications contained in the Computer Run Book.

    Phase 6 represents the end of the formal software development phases of the methodology.

    PHASE 7 - "Sub-System Test"

    This phase represents parallel testing of all procedures in a sub-system.

    PHASE 8 - "System Operation"

    This phase represents a parallel test of the whole system (or selected sub-systems) and the implementation of the system. Users and computer operations personnel are brought together and trained in the use of the system and walked through the entire process.

    Following this, the system is ready for routine operation.

    PHASE 9 - "ISEM Evaluation"

    Phase 9 is used to conduct an operational review of the entire system. Based on the earlier design manuals, the system is reviewed to determine how well it performs according to specifications. Also, actual project figures are reviewed to determine how well the original estimates and schedules were met and to calculate the total cost of the project.

    The formal deliverable resulting from this phase is a "System Evaluation Report" which contains the findings as mentioned above.

    If a design change is introduced during a phase, it may be necessary to back-up a few phases to implement the change before moving forward again. In this situation, it is similar to a mini-modification/improvement project. Because design decisions are being captured and controlled, it is a relatively simple matter of implementing changes during the execution of the project. Further, the review points should not necessarily be considered an impediment to progress. Unless the Project Manager absolutely forbids continuation without approvals, projects can proceed to the next succeeding phases while the formal reviews are being conducted.

    With ISEM, sub-systems can be designed, developed and installed individually as opposed to all at once. In fact, parts of a system can be installed and made operational while other parts are being designed, programmed and tested. This allows the maximum flexibility for controlling and delivering applications. Because systems exchange data, the Data Resource Management function oversees and coordinates the use of data throughout the development process, thus preventing data redundancy and promoting integration.

    This system modularity also influences project management. Sub-systems can be packaged and priced for users in terms of the estimated time, cost, and delivery schedule for each. This provides the user with the flexibility to determine which portions of the system they wish to pay for and when to expect delivery.

   

     

    PROJECT PLANNING & IMPACT ANALYSIS

    There are basically three types of work effort associated with information systems engineering: new systems development, maintenance, and modification/improvements. New systems development represents totally new applications for an organization to build. Maintenance is the correction of errors or defects ("bugs"); it is making the system perform according to specifications. However, the majority of work for most systems development organizations is modification/improvements to existing systems.

    ISEM recognizes that systems are built by evolution, not by revolution. The day a system is installed is the day it begins to undergo change. This is because information requirements are constantly undergoing change. Because of this, ISEM recognizes that not all projects will require the execution of every phase and activity in the methodology. After all, if a pane of glass is broken, should we redesign the whole building? Obviously not. We should only perform those steps necessary to repair the pane of glass. The same is true in systems; we should only perform those phases and activities needed to implement the objective.

    All major projects featuring new development will require the execution of all ISEM phases. However, modifications and maintenance to existing systems will probably not. To determine which phases and activities need to be performed, we must first evaluate the existing system in terms of the resources used and the degree of definition. This is where an "impact analysis" is performed to study the possible effects of a proposed change that an information resource may have on other resources. For example, "impact analysis" may be used to study the effect of a potential change to a data element, output, file, information requirement, module, sub-system, etc. Based on resource relationships, a list of related resources can be assembled and analyzed.

    Based on this "impact analysis," a decision is made as to the phases and activities required to implement the request. Only the required phases and activities are selected to implement the change. For example, if a modification to a single program is all that is required, then the project may simply consist of activities from Phases 4-II, 5 and 6 (the software engineering phases).

    "Impact Analysis" and project planning is performed in Phase 1, Activity A of ISEM. From here, the project can either execute progressively through the methodology, or proceed to the required phases and activities.

    This approach eliminates the need for varying methods based on the size of a project, e.g., small, medium and large. Systems design consists of the same logical sequence of events, only in moderation. The only effort required is that specified by the change or modification.

    This approach also highlights the fact that there is no such thing as "systems life cycles" as promoted by some people in the industry. A system does not have a life cycle. It may go on forever if kept viable with change. Double-entry bookkeeping is a good example of this. Projects, not systems, have a life cycle. They have a beginning for planning, a middle for execution, and an end for review. This problem of "System Life Cycle" demonstrates the problem that the industry has with its vocabulary and concepts.  

    JAD, RAD, BPR & OTHER TECHNIQUES

    A variety of techniques may be used throughout ISEM, all of which represent "how" to perform a specific activity or activities of work. Such techniques do not circumvent the need for these activities, only how to perform them. Two techniques gaining attention are Joint Application Development (JAD) and Rapid Application Development (RAD), both of which are closely related to what is called Agile or Extreme Programming. Although both techniques represent separate approaches, they are frequently implemented together.

    The JAD technique is concerned with working closely with end-users to specify their business problem and develop a cost effective solution. This normally involves intensive meetings between end-users and developers. The RAD technique involves the use of application development aids (e.g., program generators, report writers, 4GL's, etc.) to quickly develop a program solution.

    When coupled together and managed correctly, JAD and RAD can produce positive results. However, there are legitimate dangers to JAD and RAD if improperly implemented. Such techniques can easily turn into QAD ("Quick And Dirty"), which may satisfy the problem for the moment but may cause long-term headaches later on.

    JAD itself represents active project participation from end-users; this is vital for any development effort. But if the JAD session is used to only specify outputs (forms and screens), and not clearly define true business problems and information requirements, then the wrong programs will inevitably be developed.

    RAD also shows great promise and great danger. If application development aids are implemented without a fundamental system or data architecture in place, then they will inevitably create redundant data and software resources, and erroneous information.

    Because of their nature to quickly produce software, techniques such as JAD and RAD are oriented more to smaller applications involving one or two programs, as opposed to major enterprise-wide systems.

    To implement a JAD/RAD project under "PRIDE"-ISEM, the following phase activities represent a checklist of work steps to be performed:

    Testing, of course, will need to be performed, but this will be based on the size of the application (e.g., number of procedures and programs). Also, consideration should be given to Phase 8/Activity B - "Educate/Train Users," execution of pertinent DBEM phase activities, and the Phase 9 "ISEM Evaluation."

    Without a clear roadmap, as provided by "PRIDE"-ISEM, JAD/RAD projects can turn into chaotic and frustrating endeavors. As with any development effort, planning and organization greatly enhances your chance for success.

    Business Process Re-Engineering (BPR) represents those activities within the "PRIDE" methodologies concerned with re-evaluating and, where necessary, re-designing the processes (sub-systems and procedures) needed to support the actions and/or decisions of a business function. Re-designing business processes is actually not a new concept. In fact, it is rather old and has been an inherent part of the "PRIDE" methodologies for over thirty years. Only recently have companies re-discovered the need for this type of work.

    Unlike most application development efforts focused on programming, BPR is concerned with total business processes spanning organizational boundaries and implemented by either the computer, the human being, or other forms of office equipment. Because of its up-front orientation to planning and designing total systems, BPR should be considered a precursor to software engineering. In fact, BPR simplifies software engineering by taking the guesswork out of computer processing requirements. By concentrating on systems design, programming is greatly expedited.

    BPR primarily affects Phase 2 of "PRIDE"-EEM, and Phases 2 and 3 of "PRIDE"-ISEM. Although a full "PRIDE"-EEM project would certainly be useful for understanding the enterprise, Phase 2 "Logical Enterprise Analysis" focuses on the business functions (the logical model of the enterprise) and the information requirements needed to support them. In Phase 2 of "PRIDE"-ISEM, sub-systems (business processes) are defined in terms of "what" and "when" information must be produced. In Phase 3 of ISEM, emphasis shifts to physically "who" and "how" the sub-system must be performed, using administrative and computer procedures. At this time, processing "work flows" are defined (from start to end), as well as "data flows" between the various processing components. For more information on BPR, see:

    There are other techniques described throughout "PRIDE"-ISEM. For example:

    • Client/server computing is described in Phase 1.
    • Prototyping in Phase 2.
    • Structured programming and object oriented programming (OOP) in Phase 4-II.

    Consult the Tools & Techniques section under the various activities for precisely where and when these techniques are applied in the methodology.  

    EEM/DBEM RELATIONSHIPS

    The "PRIDE" Enterprise Engineering Methodology (EEM) precedes both the Information Systems Engineering Methodology (ISEM) and the Data Base Engineering Methodology (DBEM). It is used to formulate an Enterprise Information Strategy that includes development projects for ISEM and DBEM to implement.

    Because of the close relationship between systems and data, ISEM has a close working relationship with DBEM. In Phase 2 of ISEM, sub-systems and logical files are defined. This will then normally initiate a DBEM project to support the data requirements. In Phase 2 of DBEM the Application Logical Data Base Model (ALDBM) is prepared by Systems Engineers under the supervision of Data Engineering. Data Engineering will then incorporate the ALDBM into the Enterprise Logical Data Base Model (ELDBM). Data Base Administration will then design/update the Enterprise Physical Data Base Model (EPDBM) and Application Physical Data Base Model (APDBM). The result of the APDBM is the physical file structures for programming. In other words, the DBA must deliver the file layouts to the Software Engineer in Phase 4-II of ISEM.

    Data base design is separated from system design so that a neutral third party can accommodate the data requirements for the entire enterprise, not just a specific application.

    During Phases 3 and 4-II of ISEM will define the need for working files, either manual or computer, for use in processing. This is communicated to DBEM for incorporation in the data base.

    ISEM/DBEM PHASE RELATIONSHIPS

    DBEMISEM.BMP

    DBEM Phases can be added to an ISEM Project
    or managed as a separate project.      

    WHO SHOULD PERFORM ISEM?

    There are significant differences between Systems Engineering and Software Engineering. The Systems Engineer tends to be more people and business oriented than the Software Engineer, who is more concerned with the effective implementation of technology.

    The Systems Engineer fulfills the roles of chief architect, industrial engineer, industrial psychologist, and user liaison. Essentially, they must be proficient in interpersonal relations/communications, work measurement/simplification, possess good analytical/organizational skills, and knowledgeable about how the enterprise functions. They must also be able to interface with Software Engineering.

    The Software Engineer is more in tune with computer hardware/software than the business. They typically lack the business and people skills as possessed by Systems Engineering. This is not to demean their role, only to clarify it. Although Phases 4-II, 5 and 6 are the principal phases where the Software Engineering works, this does not limit their involvement in the methodology. In fact, Software Engineers actively participate in the early phases of ISEM in a consulting capacity to Systems Engineers. During these phases, the Software Engineer analyzes the viability of designs as prepared by Systems Engineering, as well as participate in project estimating/scheduling activities. This participation in the early phases promotes cooperation and communications between the two functions.

    OTHER FUNCTIONS PARTICIPATING IN ISEM

    As in any other work effort, Project Managers are required to plan, estimate, schedule, and control an ISEM project. Further, Quality Assurance personnel review and verify deliverables resulting from the various phases of the methodology.

    End-users are interviewed and consulted during the course of an ISEM project. As a result, their participation is vital. In fact, some of the most successful applications of ISEM has been where the user serves in the capacity of Project Manager.

    What is absolutely critical to the success of any systems project is Data Resource Management. As such, Data Engineers and Data Base Administrators actively participate in a consulting capacity throughout ISEM. In the absence of a Data Resource Management organization, the Systems/Software Engineers must assume the responsibilities.  

    BENEFIT$

    The benefits of Information Systems Engineering are numerous:

    • It assures that systems development personnel are "doing the right things," building systems that satisfy the information needs of the business.

    • Provides for improved control over the systems development process by simplifying the work effort.

    • It demystifies the systems development process.

    • It improves the performance of the development staff through a standard and consistent approach.

    • Improved communications between end users and the development staff, as well as the development staff internally.

    • Improved consistency and quality of systems.

    • Systems behave reliably and are easier to maintain and modify.

    • Improved software engineering productivity by promoting total systems engineering.

    • Improved control over project planning and execution.

    • Improved corporate control over information resources.

    • Competitive edge through accurate and timely information under changing conditions.

   

Copyright © 1971-2008 by M. Bryce & Associates
Palm Harbor, Florida, USA
All rights reserved.