【应用架构】UH信息系统课程
视频号
微信公众号
知识星球
1. 任务说明和项目概述
2. Historical Perspective on Information Systems. (JMJ)(02/24/200)
3. Information Systems - An Introduction (TM)( revised 04/07/2000)
4. Development of Information Systems (TM)(04/11/2000)
4.2 Determining need and performance expectations
4.3 Characteristics of good IS talent
4.4 Stages in Process design
5. IS modeling (TM)(03/22/2000)
5.1 System design
5.2 Stages in IS modeling
6. Methodologies for IS development
6.2 Techniques ( TM )
6.3 Tools (TM)
6.4 Methodologies (TM)
7. System Design and modeling: (MR)(04/08/2000)
7.2) System Modeling.
a) ERD (Entity Relationship Diagrams)
b) STD (State Transition Diagrams)
c) Context Diagrams.
d) DFDs (Data Flow Diagrams)
e) Data Dictionary (DD) ( revised 04/08/200)
8. IS application models in industry (TM)(03/22/2000)
9.1 Financial Information System model
9.2 Production/Operations System model
Integration of subsystems through the Information flow in production/operations system
9.3 Marketing Management Information System model
9. Current and Upcoming Strategic Issues and Opportunities in IS. (JMJ)(03/27/2000)
10. E-Commerce and EDI
11.1 E-Commerce (TM) (04/09/00)
11.2 Electronic Data Interchange ( EDI) (MR) (04/09/00)
11.3 E-Commerce and EDI (MR) (04/09/00)
11. Interfaces.
12.1 Computer Assembly (MR) (04/16/00)
12.2 Software loading (MR) (04/16/00)
12.3 Distribution and Transportation System (TM) (04/16/00)
12. Glossary of terms. (JMJ)
CHAPTER 2
HISTORY OF INFORMATION SYSTEMS (JMJ)
信息系统（IS）的历史只跨越了五十年。然而，自成立以来，IS在将商业和工业扩展到全球市场方面所做的工作比历史上任何其他公约都多。今天，信息系统的主干被称为万维网、互联网，或者与企业一起被称为局域网，以及缩写词的流行词列表；EDI、EIS、ERP、SCM和许多其他技术来描述可以采用IS来发展业务的新方法。
与今天的信息速度相反，就在四十多年前，美国的商业环境正经历着前所未有的战后增长。经济增长的许多经验都是在第二次世界大战期间学到的，当时各国的工业都在生产一台有效的战争机器。为了赢得这场战争，在这场推动下发展起来的领域是作战研究（OR）。战争结束后，那些参与OR的人被从政府工作中释放出来，从而将一个有经验和高技能的领域释放到商业和工业中，这是历史上前所未有的，这使美国进入了一个持续了20多年的繁荣和增长时代。第二次世界大战也见证了第一批实用计算机或图灵机的诞生，它们负责破解德国代码，并向盟军发出敌人动向的预警。按照今天的标准，这些第一台实用的计算机并没有那么实用，价值50万美元，而且功能远不如今天花不到10美元购买的袖珍计算器。然而，这些第一台计算机为运营研究人员提供了开始模拟更大、更复杂的系统所需的能力，这些系统在商业和工业中有助于将资本支出用于盈利企业。这种来自模拟、OR和新技术早期的背景催生了对信息系统领域的研究。
它们是何时以及如何首次使用的？正规化了吗？
到了60年代中期，IS已经进入了商业主流。虽然计算机对大多数企业来说仍然遥不可及，但电信业凭借TELEX机器崭露头角。这一步骤使企业能够在世界任何地方、任何时间在自己的组织内进行沟通，并有效地传递指令和信息。
计算机在商业和工业中的使用通常始于会计部门。人们认为这一领域对使用数控机床了解最多，而对数据库在其他业务领域的重要性缺乏了解。此时，许多商学院开始开发管理信息系统（MIS）程序，以满足IS管理者日益增长的需求。
在七十年代，更多的高层管理层认识到信息系统的重要性及其给企业带来的灵活性。TELEX成为信息传输的标准，大型计算机成为数据库创建的标准。随着对有组织、方便地访问数据的需求变得明显，基于信息的企业开始将大型机从会计管理下转移到自己的部门。
IS设计的方法以及为什么？
随着IS开始在公司中获得自己的自主权和巨额预算，这些新部门的许多精通技术的经理开始自行在系统和软件上花费大量资金，许多时间花在所有其他部门上，而没有任何业务回报。对于首席执行官决定将业务引入基于信息系统的系统来说，这是一个麻烦和危险的时期。系统和软件是复杂的，不断变化，了解系统的人往往有自己的议程。从这场动荡中产生了IS如何在企业中发展的基础。
Mainframes Vs PCs
这种现在被称为电子邮件的新热潮是由迷你和微型计算机的发明带来的，与大型机相比，它可以以非常低的价格将整个系统放在高管办公桌上，并且能够拥有一个自主系统，而无需支付巨额资金来处理信息。信息系统和企业的关系再次陷入动荡，软件和硬件供应商开始要求企业转换业务风格，以适应计算机系统。软件和硬件几乎没有标准化，许多初创公司在没有任何技术或系统支持的情况下倒闭，导致安装全新系统的支出超过预算。由于希望用信息系统支持公司的不同部门，以及硬件和软件的新可负担性，每个部门开始独立于信息系统部门将信息系统程序组合在一起。这在公司中产生了一个新的职位：首席信息官，这个职位在当时的许多公司中都可以与首席执行官相媲美。这一职位的需要是使所有部门之间的所有电子数据接口（EDI）标准化，以便更有效地提供信息。
Quality Initiatives in IS Development
80年代中期，大多数制造业公司开始转向IS来预测销售额、接受订单和管理产品分销。时代伯纳斯-李于1989年开发了万维网。在已经构建的现有互联网上使用的这种协议HTML开启了一个世界从未见过的EDI新时代。到了20世纪90年代中期，很明显，如果没有一个在自己的墙内以及与供应链供应商和分销商建立联系的可靠运作的信息系统，公司就无法有效地开展业务。EDI曾经被称为电子数据处理（EDP），现在利润率非常低，任何不做好准备的企业都将在未来五年内倒闭。
IS是一个技术驱动的系统。如果没有它，生意就不会是今天的样子。在过去的四十年里，它已经发展成为业务的中坚力量，但在20世纪60年代和70年代创建的简单应用程序规则在任何应用程序中仍然非常相关，无论数据或信息应用于何种业务模型，无论其复杂性如何。
CHAPTER 3
INFORMATION SYSTEMS - AN INTRODUCTION (TM)
基本上，信息系统处理支持业务或某些其他操作的信息流和维护。它包含有关组织内或组织周围环境中重要人物、地点和事物的信息。信息来源于对数据的有意义的解释。数据由代表组织中发生的事件的原始事实组成，这些事件在被组织成人类可以理解和有用的形式之前。
从技术上讲，信息系统可以定义为一组相互关联的组件，用于收集（或检索）、处理、存储和分发信息，以支持组织中的决策和控制。信息系统的另一个定义（白金汉等人（1987b））是：
一种收集、存储、处理和传递与组织（或社会）相关的信息的系统，其方式是使希望使用该信息的人（包括经理、员工、客户和公民）能够访问和使用该信息。信息系统是一种人类活动（社会）系统，可能涉及也可能不涉及计算机系统的使用。此外，除了支持决策外，信息系统还帮助员工和管理人员分析复杂问题，开发新产品，并集成各种模块和部门。此外，跨部门沟通的“传输损失”大大减少，从而在整个组织内实现更好的协调和提高透明度（信息共享）。
三项活动提供了组织所需的信息。这些活动是输入、处理和输出输入”包括获取“原始数据”，通过“处理”将其转换为更有意义的“信息”包。处理后的信息现在流向也称为“输出”的用户或活动。对不足之处进行分析，并将信息发送回组织的适当成员，以帮助他们评估和完善输入。这被称为“反馈”。
“信息输入”的例子是交易，这些事件将以排序、列出、合并和更新的形式进行“处理”，从而产生“输出”，如详细的报告、列表和摘要。另一个例子是制造环境中的“信息输入”，如设计规范、材料要求和SOP（标准操作程序）。这些将由信息系统通过建模和仿真技术进行“处理”，并将产生标准生产模型以及生产过程的总成本，该总成本由信息系统根据包含材料成本、小时人工成本和其他间接成本的知识库计算。因此，几乎完全消除了事物计划中的一个独特的成本函数。
然而，信息系统不能仅仅被广义地描述为真空中的输入过程输出机制。它需要为商业环境中提出的挑战和问题提供主要的组织解决方案。因此，管理者不仅需要精通计算机，还需要对整个组织结构和职能有一个很好的了解。这一概念如首页的图所示。
此外，问题的核心是信息系统不应与信息技术混淆。它们相互独立地存在，无论它们是否得到很好的实施。信息系统使用计算机（或信息技术）作为存储和快速处理信息的工具，从而进行分析、决策以及更好的协调和控制。因此，信息技术构成了现代信息系统的基础。
3.1 Types of Information Systems
信息系统的类型
（资料来源：管理信息系统，Laudon和Laudon）
与每个组织级别（上图所示的四个级别）相对应的六种主要类型的信息系统是：
- 交易处理系统（TPS）：服务于组织的运营层面。
- 知识工作系统（KWS）
- 为一个组织的知识水平服务的办公自动化系统。
- 决策支持系统（DSS）
- 管理信息系统（MIS）服务于组织的管理水平。
- 高管支持系统服务于一个组织的战略层面。
(Source: Management Information Systems, Laudon and laudon)
CHAPTER 4
信息系统的发展 (TM)
如前所述，每家公司一开始都有一个信息系统，无论是基于文件卡和铅笔的系统、计算机系统还是两者的中间系统。因此，信息系统的开发过程涉及到对现有系统的工作——绘制系统地图，使其自动化，并确保其根据用户需求运行。因此，在其第一阶段，该过程试图确定用户想要的新系统的范围和类型。下一阶段将分两部分分析上述需求，以便于在系统实际设计和实施之前进行详细的验证和确认。
4.1从用户开始
事实上，信息系统开发的整个概念都围绕着用户——他们的需求、性能期望、需求和其他规范。信息系统的成功或失败可以通过其基本用户在组织中的满意度来衡量。数据库必须满足用户的要求，否则他或她将继续使用自己的系统，从而破坏中央数据库的目的。这一概念的关键要素是，每个子系统都使用相同的数据库来满足其信息需求。这将产生一个额外的显著优势——部门和职能的整合。因此，每个部门通过其对公司总信息资源的访问和接口，对其行动和计划如何影响整个组织的其他人有了更好的理解和欣赏。
可以提出的一个重要问题是，为什么在构建信息系统之前分析和设计信息系统很重要。为什么你不能直接建立信息系统？主要原因是：
1.建立用户真正需要的信息系统很重要。如果你不从某种分析和设计开始，你就不知道他们真正需要什么。
2.在没有足够好的“蓝图”的情况下构建信息系统是浪费资源，因为如果没有蓝图，会花费更多的时间，产生更糟糕的结果。
进行分析和设计是为了满足信息需求。如果需要建立描述用户真正需要的信息系统的模型，那么兴趣组（或用户组）通常必须参与这项工作。进行分析和设计的另一个原因是，参与这项工作的人对新的信息系统了解很多。为了能够使用信息系统，需要了解这些系统是如何工作的。参与分析和设计工作是获得这些知识的一种方式。
4.2确定需求和绩效预期
由于每家公司都有一个现有的系统，IS开发过程涉及系统转换。转换过程中涉及的一般步骤是：
- 系统描述（叙述或图片）
- 输入文件（项目描述、布局等）
- 输出文件（报告格式、输出要求等）
- 文件设计（涉及下一节中解释的系统设计过程）
- 程序逻辑（通过使用流程图或其他方法）
- 计算机程序（COBOL、DYNAMO、BASIC、PASCAL、FORTRAN等）
- 系统验证
- 文件
围绕数据库建设的潜在问题需求通常是与部门间协调和协议有关的需求。这些可能包括：
- -希望维护信息安全的单位输入信息无效的可能性。
- -错误输入数据的“乘数效应”，对使用数据的其他部门产生直接影响。
- -输入数据的“时间维度”，要求用户部门就交易应反映数据输入的时间达成一致。
- -关于数据库数据元素中包含的详细程度所需的“部门间协议”。
由于已经识别出的上述问题，系统的一些期望特征将是：
- -简单或易于使用和处理（通过使用基于图形用户界面的输入和检索系统）
- -足够的安全功能/防火墙，用于限制未经授权的访问（包括组织内部和
- 在网络上）和
- -一个非常严格的骨干操作系统，用于支持不同级别的众多组织功能。
对正在开发的系统的期望或要求有明确的了解，就需要列出一些性能指标。衡量成本或收益是衡量新旧之间的变化。换句话说，我们可以测量系统总输出的变化，或者测量整个系统完成的许多变化。前者显然是最可取的。
尝试在系统级别上对整个系统进行测量可能是罕见的。在系统开发过程中需要牢记的一些广泛概念包括：
- 1.系统完整性：在没有冗余的情况下，子系统集成到整个系统中的情况如何？灵活性如何
系统？系统扩展的容易程度如何？
- 2.操作完整性：操作系统的人员有多熟练？有什么备份可以防止系统
在关键人员损失或设备故障的情况下发生故障？
- 3.内部完整性：系统在多大程度上完成了它应该做的事情？系统输出的有效性如何？怎样
系统是否安全，防止人为错误、操纵、破坏或盗窃？
- 4.程序完整性：系统和程序的文档有多好？程序是否
员工是否有动力追随他们？在实践中遵守程序的情况如何？哪些控制措施可确保
遵守程序？
-在进行信息系统开发之前，必须进行变更分析。变化分析是在具体情况下对企业活动的适当变化进行分析。变化分析的目的是在你开始解决问题之前制定问题。只有当你有信息系统问题或需求时，开发信息系统才是有效的。在执行面向数据的工作之前，必须执行面向问题的工作。
信息系统开发中的面向问题的工作是指以指定信息系统将要做什么为目的的开发部分（从用户的角度来看）。面向数据的工作是指要为本规范设计技术解决方案的开发部分。只有以面向问题的规范为基础，才能有效地执行面向数据的工作。
在流程设计的第一阶段（即需求分析）中对这一概念进行了进一步详细的解释
4.3 Characteristics of good organisational IS talent
A manager needs information for a variety of reasons concerned with the management process. The type of need that he or she will have at various times and for various purposes depends largely upon 2 factors that we shall examine briefly : the personal managerial attributes and the organizational environment in which decisions are made.
Personal Attributes
1 . Knowledge of information systems
If managers are aware of what computer-based systems can do, their information requests will probably be more sophisticated and more specific. Their knowledge of capabilities and costs places them in a much better position to aid in the design of a good system.
2. Managerial Style
A manager's technical background, leadership style, and decision-making ability all affect the kind and amount of information required. Some prefer a greater amount; Others like to decide with a minimum of detail and prefer personal consulatation with subordiantes.
3. Manager's perception of information needs
" You tell me what I need to know" and "get me all the facts" represent two opposite perceptions of information needs. This dichotomy is due partly to the fact that many managers are ignorant of what information they need. Another dimension of the problem is the widely differing views of the managers regarding their obligation to disseminate information to subordinates and to groups outside the firm. Teh manager wh ocannot or will not delegate authority is likely to keep information closely held.
Organisational environment
1. Nature of the company
Problems in communication and in controlling operations seem to be a function of the comapny's size and the complexity of its organization. The larger more complex firms require more formal information systems, and the information needs of these systems become more critical to operations.
2. Level of Management
There are three levels of management (i.e strategic planning, management control, operation control) and the varying needs for information at each. Each level needs different type of information, generally in different form. top levels need the one-time report, the summary, the single inquiry. The management control level needs the exception report the summary and the variety of periodic reports for regular evaluation. The operational control level requires teh formal report with fixed procedures, the day-to-day report of transactions, to maintain operational control of actions as they occur. Managers at all levels have changing information needs, depending on the nature and importance of the particular decision.
3. Structure of the organisation
The more highly structured the organization, the easier it is to determine the information needs. Where authority and responsisbility are clearly speelled out, relationships understood, and decision-making areas defined, the information needs of managers can be determined more easily.
(Above section adapted from Information systems for modern management by Murdick, Ross and Claggett)
4.4 Stages In Process Design:
The Process of information systems development in its first phase attempts to determine the scope and type of system the user wants. The next phase analyzes the above requirement in two parts to facilitate detailed verification and validation before the system is actually designed and implemented.
Requirements Determination
This stage consists of obtaining user needs and requirements which reflect the user-expectations from the IS being developed. It consists of several stages:
1) Problem definition
2) Feasibility Study
3) Requirements Acquisition
4) Requirements Analysis
The problem definition and feasibility study stages consist of definition of a bare outline of the desired system. The Problem Definition Stage defines to a high level of detail the application for the desired IS and an indication of the advantages that will result from its implementation. The Feasibility Stage is the examination of the different alternatives with which a solution can be found for the design of the desired system. The Requirements Acquisition Stage results in a "statement of requirements". The Requirements Analysis stage produces the "requirements specification". Using the 'statement of requirements' as the main input the aim of the requirements specification is to act as an overview of the desired system in a structured form.
Analysis Phase
This phase analyzes the requirements from the previous phase and converts them into components, which are used to build a 'specification' of the desired system. The specification is more precise than in the previous phase and adds more detail, at the same time retaining user semantics, so that the description would be recognizable to the user. However the model is at an abstract level, that is, with no details concerning data representation or computer implementation.
Logical design
This phase produces a design of the desired system that will serve as a basis for computer implementation. There are two major tasks in logic design. Firstly the specification from the analysis phase is transferred and secondly the human computer system is designed. The significant difference in this phase is that the structure component is now represented by data. There will often be several possible ways of representing relationships. We may also use normalization in this phase. We decide exactly what data types are required for data representation, how many characters are required for each data item and we design records and files or databases to store the data, taking into account the type of processes that will operate the data. An abstract programming form is often used here, such as structured English, JSP diagrams or action diagrams. In addition DFDs may be drawn showing the processes that occur, the data input to and output from each process etc.
The second major task in logical design consists of design of human computer systems. Two levels of detail are normally considered here:
- Design of user procedures which consist of tasks and processes with which users will be directly involved
-Computer interface design consist of the detail of processes and the objects on which these processes operate, and may involve considerations related related to interaction style ( screen and report layouts, human-computer dialogues), specifications of manual or mechanical operations, and off-line or online processing.
Physical design
This is the last of the design phases. We may consider it as consisting of 3 components: Hardware, software and human-computer systems. The hardware design consists of a description of the computers, storage devices, input/output devices and possibly networking devices required for the desired system.
Software consists of the programs that run on the hardware. The physical design of data needs to be considered as the kind of data invariably affects the programs that process the data. It will be necessary to decide on the appropriate types of applications software, including languages and packages as well as systems software required for supporting the eventual system.
Process Design
There are four options for process design
1. For standard processes, we can buy packaged software. For example, accounting software is largely standardized.
2. Use of a fourth-generation language such as lotus123, VB, Oracle etc.
3. Generate code using a CASE tool
4. Write our own code.
If in-house coding is done data structures are chosen for the representation of data in the programs, together with decisions as to the programming language required for eg. COBOL, C++ etc. Issues such as execution speed and ease of maintainability of program code are considered.
Human Computer system design
Some of the design of this system specifies the activities to be followed when communicating with the computer, for example, detail of dialogue between computer and operator, procedures for starting-up and shutting down the system and screen contents such as windows or colors etc.
Implementation And Testing
The major output of the implementation and testing phase is a physical information system and not a design. Of course the physical and earlier designs remain available for reference, as they form the specification. The major tasks consist of:
- Acquiring and integrating hardware, producing software, generating data for the files or databases and producing the human-computer system.
- System is tested, user comments are evaluated, perhaps to redesign the system.
- The operation of the implemented system in the user-organization if monitored closely for a limited period.
Maintenance
The maintenance phase consists of correcting errors in the system or responding to changes in the user requirement, due, for example, to environmental changes or personal preferences for system operation and it may require reworking of all the previous phases for the part of the system that requires changing.
信息系统建模
5.1 System Design
The basic information model consists of three parts as shown below and the data dictionary. The external models represent the user views of the system. These are brought together into a single global conceptual model as illustrated below. The conceptual model does not take into consideration how the data and processes will be implemented on the computer. This is accomplished through the internal model (shown as 'schemas' and 'programs' in the diagram below)
5.2 Stages in IS modeling
As mentioned earlier, we do not design the internal model right away. A conceptual information model is first formulated and this is then translated into an internal model. Also we need to develop two conceptual models
(a) A conceptual data model and
(b) A conceptual process model.
These are then checked for consistency and, any necessary modifications are made to arrive at the data processing model. This is the first level information model. (the data model, the process model and the data processing model) otherwise called first level design.
Second level design is concerned with adapting the first level design to the specific requirements of the processing required. It may be that the first level design consists of so many relations that it would not achieve an acceptable level of performance if it were implemented in that form. Hence the model may need 'flexing' to accommodate the demands of the functions which the information system may support. The result of this is the second level design information model.
The final stage is the third level design where the model is mapped into the internal schemas required by the software being used to implement the system.
The process of moving form first to second to third level design may seem rather long but it is important for a number of reasons. The first level will provide a transaction-independent view of the information content of the system. However it will still be enterprise-dependent because the data model will only reflect the things of interest to that enterprise. The second level design is enterprise or transaction dependent, but is still independent of hardware and software. Hence the second level can be used to evaluate alternative implementations and assist in the selection of hardware and software. Third level design is enterprise, transaction and software dependent.
The process of design is shown in the diagram below. IT is important to note that this process does not equate the design of the entire information system. In particular it does not cover data on establishing the feasibility of an IS, nor on strategic decisions involved in selecting an information area. Similarly nothing is said about the design of forms, codes, screens and reports nor of the techniques for the analysis of the requirements of the users.
第六章
IS开发方法
6.1 System Development Methods (MR)
( Source : Yourdon system methods, model driven methods, 1993)
The evolution of system development methods has been gradual. The three stages in the evolution of system development methods may be identified as :
1) First generation methods.
2) Second generation methods.
3) Third generation methods.
First Generation Methods
These methods includes various "structured techniques" developed during late 1960s and
1970s. Structured techniques breakdown a complex problems into smaller components with
well defined inter-relationships between components. " DIVIDE and RULE "
Components of First generation methods:
1) Structured programming.
2) Modular design and structure charts.
3) Programming style.
Modular design : many programming languages allow groups of statements to be reused, such a group
of statements are called program module and their use is referred as modular programming. structure charts
show how modules are connected to form a program.
Programming style: using standard constructs, code can be complex and difficult to understand and it was also understood that maintainable code also required style guidelines ( 1970s).
Data Structures: data design tech. used in 1970s were pragmatic ways of building data structures and files to support programs. CODASYL organization was upfront in database design in late 60s.
Structured Design: structured programming technique only addresses "design in small" , these never gave any guidelines on how to carry out "design in the large".
Successive refinement (Top Down Functional Design): A required system function was broken-down to smaller number of tasks that could be combine to accomplish the function. Each of these were in turn broken down into smaller sub-tasks. The process was continued until the subtask was so simple that it could be coded with little chance of error.
Techniques based on the semantics of the structure chart
Main criteria for improving program design were based upon :
- Coupling: measures the complexity of interfaces, If interfaces between module are simple, design is described as having low coupling.
- Cohesion: measure of how " single-minded " a module is. If module carries out exactly one well defined function it is described as having functional cohesion.
Data Refinement: Relation data model, which treats all the data as "tables". Refinement criteria were used to check the quality of design. Application of these criteria is called normalization.
Structured Analysis: The set of tools and techniques referred to as " structured analysis " were developed to address the problem of identifying and stating the user requirement in an unambiguous, understandable form. These techniques were mainly "Process-oriented" concentrating on required system functions.
Modeling tools : The main need was for modeling tools that would help to partition complex requirements into smaller units with well defined inter-relationships. The modeling tools used were :
1) Data Flow Diagrams to show the portioning of proposed system into smaller functional areas or "mini-systems".
2) Mini-specs to specify each "mini-system".
The use of review sessions, where part of the requirements was also presented was a key technique capturing user requirements. These review sessions were termed as "structure walkthroughs".
Information Modeling: at the same time as structure analysis were developed, a semantic approach to information modeling was formulated. This was based on real-world entities and relationships.
Problems with top down functional decomposition (TDFD) :
Top down functional decomposition was carried out by trying to guess what main functional area were. Each functional area was then examined in turn and successively broken down until the functions were simple enough to verify with the user.This lead to second problem that caused TDFD to be supplemented or replaced in the second generation methods.
Analysis-Paralysis
Correct partitioning of the system could not be done until system was understood and system couldn’t be understood until it had been partitioned. Because of this problem an optimal statement and organization of the user requirement was very time consuming, required considerable reworking of the models and due to time pressure it compromise on quality of work.
Analyst Bias
TDFD is creative technique and reflects the way the analyst thinks or perceives the system. The logical model tends to reflect the unconscious bias of analyst towards a specific solution.
Fragmentation of Policy
Although there were guidelines that helped identify the best organization of the user requirements,it was sometimes found that functions which were widely separated in the model needed to be cross-checked.
Different system development philosophies:
1) Process and data driven methods.
2) Phase oriented and model oriented development.
Process oriented: concentrating on system functions and regarding the data as only being present to support system functions.
Data Driven methods: Concentrating on information requirements, particularly in terms of identifying the data to be stored in database. Systems functions were considered to be less important.
Phase oriented : System development life cycle was seen as sequence of phase, each consisting of well defined activities that had to be carried out.
Model oriented : here life cycle was seen as a sequence of models of system requirements. Each model had a defined structure that could be checked.
Second Generation Methods
- In First Generation (FG) methods developers were process oriented or data oriented and used modeling in fairly informal way. In all Second generation methods main stress is on the construction and checking of models.
- FG methods are largely independent approaches for dealing with each stages of system development life cycle. Second Generation methods provide a smoother development path from requirements analysis to later design and implementation stages.
- FG model is used to capture system requirements in policy terms, later models elaborate on how the model is mapped onto available technology because models are not independent but each model evolves into the next, taking into account another layer of technology.
- FG methods viewed system from one viewpoint with relative poor modeling from other viewpoints.SG methods regard system functions and data as two equally important aspects the system.
Second generation methods were externally oriented :
Analysis techniques are based on real world requirements of two types
a) response to real world events and
b) store information about real world entities.
Real World Events : Time is more explicitly modeled in terms of events that occur in the environment of system.System behaves as they do only because of these events that occur and requires policy for responding to these events.
Real World Entities : By collecting information about real world entities and the relationships between them, the analyst avoids bias towards any possible data storage organization.
CASE (Computer Aided Software Engineering )
Use of CASE was not common until 1980s although such tools become available from about 1975.Some case products have "draw what u want "approach and some have "more well defined grammar that the diagrams can be checked against".
The second generation technique are mainly " Diagram Oriented" unit of modeling is a diagram. Diagrams are drawn and checked.
Reasons For Third Generation Methods
The second generation view of models is rather low-level.It deals with individual diagrams rather than the larger issues of how individual analysis and design unit fit together and interact.
Third generation methods will be distinguished by a philosophy that is more concerned with the whole rather than parts.
6.2 Techniques (TM)
An information systems development methodology can be defined as a collection of procedures, techniques, tools and documentation aids that will help the systems developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of sub-phases, which will guide the systems developers in their choice of techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate IS projects.
Definition of terms:
Methodology: As defined above it basically represents a way to develop IS systematically. Techniques: May involve the use of one or more tools which represent some of the artifacts used in information systems development.
Tools : Tools are usually automated, that is, computer tools normally software to help the development of an IS.
Techniques may be used in common among several methodologies. However they are not interchangeable because when used in a particular methodology they could address different parts of the development process, be used for different purposes or be applicable to different objects. Listed below are the techniques used in the information systems development process:
- 丰富的图片
- 根定义
- 概念模型
- 实体建模
- 规范化
- 数据流程图
- 决策树
- 决策表
- 结构化英语
- 动作图
- 实体生命周期
- 对象定向
- 结构图
- 矩阵
The above table shows the position or stage in the development where any particular technique is utilized and whether it is primarily regarded as general, or data or process-oriented.
The asterisk indicates the IS development stage or stages (discussed previously) in which the technique is most commonly used. For example entity modeling is used in two stages but its use at the logical design stage is most common.
6.3 Tools (TM)
Tools (especially automated tools) are available in plenty for the system development process. Listed below are a few tools classified (and thereby defined) into some significant groupings.
1. Project management tools
2. Database management systems
3. Data dictionary systems
4. Systems repositories
5. Drawing tools
6. CASE (computer aided software engineering) tools
Methodologies for information systems development make use of some of the process-oriented techniques of functional decomposition such as data flow diagrams, decision trees, decision tables and structured English. Functional decomposition gives structure to the processes reflected in particular by the most important technique of data flow diagrams. This emphasis on structure gives the name of the first methodology STRADIS.
Some of the several methodologies proposed for IS development include:
- STRADIS (Structured Analysis And Design of Information Systems) follows the Top-down approach (functional decomposition) for analyzing processes.
- YSM (Yourdon Systems Method) Although, at the outset, this was very similar to STRADIS it differs in the more recent versions wherein it follows a middle-up approach' to analyzing processes also called as event partitioning, which is more appropriate than the top-down approach. As a result of some such features as the above and also due to better ease of understanding and clarity of depiction, we employ the YSM in our future study and analysis of IS in industry.
- IE (Information Engineering) : Whereas the fundamental techniques of the above two process-oriented approaches are functional decomposition and data-flow diagrams, the basic approach in IE is the data-oriented entity relationship approach.
- SSADM (Structured systems analysis and design methodology) : It can be said to be the modern version of the traditional Information systems development life cycle approach. It includes the techniques of data flow diagramming and entity life histories, and recommends the use of tools, such as CASE tools and workbenches.
- Merise Unlike as in the previous methodologies wherein emphasis has been placed on either process or data aspects, Merise has been designed such that both are considered equally important and these aspects are analyzed and designed in parallel.
- JSD (Jackson Systems Development) is the development of Jackson systems programming (JSP) (which has had a profound effect on the teaching and practice of commercial computer programming.) into systems development as a whole. This methodology concentrated on the design of efficient and well-tested software, which reflect the specifications and is particularly applicable where efficiency is of paramount importance, for example in process control applications.
- Object oriented Analysis : This approach reflects the view that in defining objects and their component parts (attributes) we capture the essential building blocks of information systems. Also it is a unifying approach as analysis and design can be undertaken following this approach.
- ISAC (Information Systems Work and Analysis) This methodology seeks to identify the fundamental causes of users' problems and suggests ways in which the problems may be overcome (not necessarily through the use of computer information systems) by the analysis of activities and the initiation of change processes. It is therefore a people-oriented approach with emphasis on the analysis of change and the change process. (Source: Information Systems Development: Methodologies, Techniques and Tools by Avison, Fitzgerald)
- ETHICS ( Effective Technical and Human Implementation of Computer based Systems) : Also a people-oriented approach and encompasses a socio-technical view that, in order to be effective, the technology must fit closely with the social and organizational factors in the application domain.
- SSM (Soft Systems Methodology) : Whereas most of the earlier approaches stress on scientific analysis, breaking up a complex system into its constituent parts to enable analysis, systems thinking might suggest that properties of the whole are not entirely explicable in terms of the properties of its constituent elements. SSM addresses the 'fuzzy', ill-structured or soft problem situations which are the true domain of information systems development methodologies, not simple technical problems.
- (Source: Information Systems Development: Methodologies, Techniques and Tools by Avison, Fitzgerald)
- Multiview is a hybrid methodology that brings in aspects of other methodologies and adopts techniques and tools as appropriate. Basically a contingency approach : techniques and tools being used as the problem situation demands.
- Process innovation does most to tie business process reengineering with information technology and information systems, IT being seen as the primary enabler of process innovation as it gives an opportunity to change processes completely.
- (Source: Information Systems Development: Methodologies, Techniques and Tools by Avison, Fitzgerald)
- RAD (Rapid application development) is in response to the need of rapidly changing business environments. It is usually enabled by CASE tools and systems repositories.
- KADS is the outcome of a European research project to develop a comprehensive, commercially viable methodology for knowledge-based systems construction..
- Euromethod also results from a european initiative and is more of a framework for the procurement and management of services for the investigation, development or amendment of information systems than methodology.
(Source: Information Systems Development: Methodologies, Techniques and Tools by Avison, Fitzgerald)
CHAPTER 7
SYSTEM DESIGN AND MODELLING (MR)
7.1 Business Process Redesign
(Ref: Engineering management review (Vol 26 ,number 3, fall)
Business Process Redesign is defined as "the critical analysis and radical redesign of existing business processes to achieve breakthrough improvements in performance measures."
In 90's 2 tools revolutionised the organisations these were :
1) Information Technology
2) BPR ( Business Process Redesign )
IT : This includes the capabilities offered by computers, software and telecom. IT is considered as analysis and modeling tool. Thinking about IT should be in terms of " How it supports new or redesigned business processes.
Use of IT in Manufacturing Industries :
a) Process Modeling.
b) Production Scheduling and Controls.
c) Materials and Management Information Systems.
d) Logistics.
Business Process ( BP ) : Business processes are defined as set of logically related tasks performed to achieve a defined business outcome.Set of business processess forms a business system.
Business processes have two important characteristics :
a) They have Customers : Recipients of outcome.
b) They cross Organizational Boundaries.
Five steps in (PD) Process design :
1) Develop Business Vision and Process Objectives : Prioritize objectives and setstretch targets.
2) Identify the Process to be Redesign : To find out critical processes.
3) Understand and measure existing process : Identify current problems.
4) Identify IT levers : To think of new process approach.
5) Design and build a prototype of the process : Implementation.
Develop Business Vision and Process Objectives.
In past process redesign was to rationalize the process, i.e to eliminate obvious
bottlenecks and inefficiencies.
Most likely Objectives :
- Cost Reduction : Important objective with others but insufficient in itself, while optimizing other objectives seems to bring the cost inline but not the vice-versa.
- Time Reduction : Common approach for reducing time is to make steps simultaneously rather than sequentially, using IT to co-ordinate.
- Output Quality : Specific measures may be uniformity, variability or freedom from defects. This is mostly defined by customer of the process.
Setting goals that will stretch the organization will also provide inspiration and stimulate creative thinking.
Identify the processes to be redesigned.
Two major approaches :
- Exhaustive approach
- High Impact approach
High Impact approach : Attempts to identify only most important processes
Redesign process should be containing :
b) Interfaces.
c) Organisation units involved.
Understand and Measure existing process.
This is required because :
a) Problems must be understood so that they are not repeated.
b) It can act as a baseline for future improvements.
Identify IT Levers.
Role of IT in process design should be considered in early stages of redesign. All of IT capabilities involve improving coordination and information access across organizational units, thereby allowing more effective management of task interdependence.
Design and Build a prototype of the process.
The process design after agreements by owners and stakeholders are implemented on pilot basis ( Parallel with the existing processess) examined regularly for problems and as the process reaches final acceptance, it is phased into full implementation.
Defining Process Types :
Three major dimensions can be used to define processess,
1) Organisational entities or subunits involved in the process.
2) Type of objects manipulated.
3) Type of activities taking place.
Defining Process entities :
Inter-functional Processes : Achieve major operational objective such as new product realization, asset management, production scheduling.
Interpersonal Processes: These are the processes within and across small groups. Using " electronic mail and conferencing."
Defining Process Objects :
a) Physical
In Physical object processes real, tangible things are either created or manipulated. informational object processes create or manipulate information. Adding information to a physical object as it moves through a process is a common way of adding value. Using IT to improve physical processess allows greater flexibility and variety of outcomes, more precise control of process, reduction in throughtput time, and elimination of human labor.Defining Process Activities :
b) ManagerialOperational activities involves basic business activities in the orgainisation.Mangerial activities includes control, plan or providing resources for operational processess.
Capabilities of Information Technology for reshaping management issues includes :
a) improve analytical accuracy
b) enable broader management participation
c) can generate feedbacks
d) can streamline the time and resources a specific process consumes.
To attain SCM integration, it is necessary to understand the infromation requirements of all the participants and design system that facilitate co-operation.
Why BPR Project fails ?
1) Lack of sustained management commitment and leadership.
2) Unrealistic scopes and expectations.
3) Resistance to change.
4) Narrow technical approach.
5) Cost-Cutting focus.
What can be done to make a BPR a Success ?
1) Do something smaller first ( Pilot Experiments ).
2) Conduct personal transformation ( change of mindset ).
3) Get IS and HR involved.
4) Empowered and collaborative workers support.
5) Realistic expectations.
6) Prioritise the objectives.
SUCESS OF BPR DEPENDS ON THE PEOPLE WHO DO IT AND HOW WELL MOTIVATED ARE THEY.
7.2 System Modeling
(Source : Yourdon system methods, model driven methods, 1993 )
Modeling Tools
Uses of Modelling Tools :
1) Focus on important system features.
2) Medium of communication with users.
3)Document the systems analyst's understanding for the impementation for implementation by designers and programmers.
There are 4 main types of modeling tools used inYSM ( Yourdon System Methods )
1) Graphic
2) Tabular
3) Frame
4) Textual
Graphic Tools : These are used to show high level components of particular aspect of a model. Each graphic modeling tools has set of icons used to represent specific model component. Graphic tools are preferred type of modeling tools when the connection between model components is important.
Graphic tools in essential modeling are mainly of a semantic nature highlighting the meaning of the requirements.
Graphic tools in implementation modeling are mainly concerned with syntax or structure.
Tabular Tools : Some information is usefully laid out in tabular forms. Tabular tools may be useful in some circumstances particularly if subject matter expert finds the graphic modeling tool difficult to relate to.
Frames : Frame is used informally for a certain type of specification tool. Frame specifications are used to specify all relevant info about a model component that has been declared on a diagram or another frame.
Textual Tools : Textual grammar is defined formally, using meta language or set theory.
7.2a Entity Relationship Diagram (ERD) :
ERD is semantic modeling tool used to identify and organize information and to model particular roles of importance to the enterprise and relationships between them. This may also be used as a tool for discovery of rules and events. These are not contingent on the modeler’s point of view or interpretation as these are real world facts. Enterprise Essential Model uses ERD to define entities it uses and the relationships between them. System essential modes uses ERD to show the entities and relationships that the system has responsibility for collecting or using information about.
Components of ERD :
Entity : Entity is a class of real world thing whose role of interaction with the enterprise is well-defined. Each entity has a unique name which should reflect the role that is played by that type of object. These things may be physical objects abstract concepts. Each entity must be distinct from but fulfill the same role as other occurrence of the entity. Instructor in ERD defines entity.
Relationship : relationship represent possible associations that may occur between occurrence of entities. On diagram, each relationship is shown linked by lines to entities to which it refers. "Occurrence of the relationship" represents a single instance of the association between entities.
Relationship Frame : Each relationship frame that includes the entities involved and other text forming a complete sentence.
source : Yourdon system methods, model driven methods, 1993.
Each occurrence of relationship corresponds to a specific occurrence of a "Course" and a specific occurrence of "Topic".
Binary Relationship : A relationship that refers to two entity occurrences is called binary relationship.
Higher order Relationship : A relationship involving more than 2 entity occurrences is referred to as higher order relationship.
source : Yourdon system methods, model driven methods, 1993.
When entity is repeated in relationship,the relationship is referred to as being recursive. For recursive relationships, the role for the entities must distinguished as it can be seen in the frame that employee reports to other employee who is manager.
source : Yourdon system methods, model driven methods, 1993.
If the occurrence of entities in a recursive frame is not significant the relationship is known as symmetric. The relationship " is friend of" is an example of symmetric relationship. For symmetric relationships , the role for the entities doesn’t have to be distinguished.
source : Yourdon system methods, model driven methods, 1993.
Associative Entity : This is the entity which acts as entity and relationship both. As a relationship it indicates a group of real world associations between entities. Attributes of associative entity do not describe the entities that participate in relationship but the occurrence of relationship between them.
source : Yourdon system methods, model driven methods, 1993.
a -describes a relationship.
b -date on which marriage took place is neither an attribute of "man" nor "woman" but it describe the occurrence of relationship.
marriage -associative entity
date-as an attribute.
Each occurrence of "marriage" records the fact that specific man was married to a specific woman on a specific date.
Subtype, Subtyping and Supertyping :
Subtype : Subtype of entity is a well defined group of occurrences of entity that may be regarded as entity in its own right.
Subtyping indicates that the enterprise regards the entity as being made up of number of distinct identifiable groups each of which is referred to as a subtype.
Supertype : supertype is regarded as a general grouping of several entities.
source : Yourdon system methods, model driven methods, 1993.
7.2b State Transition Diagram ( STD )
STD models time dependent behavior.In STD, each state represents a period of time during which the system exhibits some observable behavior.
source : Yourdon system methods, model driven methods, 1993.
Components of STDs
Access : Access on STD shows the possible access to the occurrence of entity when change of state occurs.
Create Access : causes a new occurrence of entity to exist , occurs for initial transition.
Read Access : for an event which occurs and requires some attributes to be used but not necessarily changed.
Update Access : used where some of attributes of entity are to be changed.
Delete Access : after this entity do not exists.
Match Access : to check whether a specific occurrence of the entity exists.
Connector : Where it is difficult to draw diagrams without crossing transaction lines a pair of connector symbols may be used. On diagram connector "op"is used in this way.
Entity : each STD is for one state variable of specific entity.Example shown is for associative entity "scheduled course". An entity may have several STD one for each of its state variable.
Entity death : this indicates that occurrence of entity no longer exists and cannot be accessed.
Event : event is the thing which causes transition to take place.When this event occurs a change of state may occur for one occurrence of the entity but it doesn't always occur.The responsibility whether or not it does occur resides in a data process.
Initial State : state of the occurrence of entity when it is created.A transition to this initial state is referred to as an initial transition and must always include "create".
State : Each occurrence of the entity have a well defined state for a given state variable. Each schedule course may have a status of "open","running", "full" or finished".
7.2c CONTEXT DIAGRAMS
This is a diagram where systems is represented as a system diagram in whole.Purpose of context diagram is to depict how the system is connected to,interacts with other entities which makes its ( data ) environment.
source : Yourdon system methods, model driven methods, 1993.
Context diagram show all external entities which interact with the system and all data flows between these and the system.
Components of Context Diagrams:
Access Flow : access flow indicates that the system uses stored data which is shared between it and its environment.
Continuous access flow : if system or a terminator continually updates or monitors the value in a store it is shown as continuous access flow.
Discrete access flow : Access toa store that takes place at a particular instant of time. Data is present in store and can be accessed anytime.
Context Process : This is a process group which represent the system.On context diagram system is regarded as a "Black Box". All requirements for behavior or data storage by the system is considered to be within this process.
Dataflow : data flow on context diagram either represents information produced within or outside the system which is used by outside world or by the system itself.
Continuous data flow : continuous data flow represents a value that is available over a period of time.
Discrete data flow : data flow that is only present for a instant of a time.
Dialogue data flow : a data flow generated by the terminator for the use of system is combined with a data flow created by the system for use of terminator.
Event Flow : indicates synchronization between the system and its environment.
Continuous event flow : represents a status that is indicated over a period of time.
Discrete event flow : event flow that is only present for an instant of time.
Dialogue event flow : pair of event flows that occur at the same time may be combined and shown as a dialogue event flow , provided that they are to/from the same terminator. Dialogue event flow is used to show a group of input flows ,together with corresponding response flows either initiated by terminator or the system.
Terminator : terminator is a producer or user of data that interfaces with the system.
Data Store : a data store on the context diagram shows an interfaces between system and its environment. The store indicates that the system and terminator are decoupled in the sense that one can change values in the store independently of the other.
7.2d DATA FLOW DIAGRAMS (DFD) :
A data flow diagram is the most important technique for modeling high level detail of the process within a system.These highlights the functions of the system and how they use stored information and transfer information between each other.
source : Yourdon system methods, model driven methods, 1993.
They show how input data is transformed to outputs results through sequence of functional transformations.
Components of DFDs :
Access Flow : access flow is used to show that a process needs to use or change stored information to accomplish its purpose.An access flow from a store show that the process uses information held in the store . This may correspond to:-
- Match Access : The process checks whether an entity or relationship occurrence matching a particular criterion exists.
- Read Access : The process uses the values of one ( or more) attributes for a selected occurrence of the entity.
- Check Access : The value of a state variable needs to be checked.
An access flow going to a store shows that the process will alter information held in the store, This may correspond to a :-
a) Create access : to create a new occurrence of an entity or relationship.
b) Delete access : to delete one ( or more) occurrence of an entity or relationship.
c) Update access : to modify the value of an attribute.
d) Change access : to change the state of a state variable.
Continuous Access Flow : In some situations it is necessary to continuously monitor the value in the store. This is carried out using data process. Link between this data process and the store is shown as continuous access flow.
Control Process : Control process coordinate the activation of processes and signal to other components of system essential model. The coordination is carried out by interpreting and generating event flows and controlling processes by triggering or enabling or disabling them.
In figure control process "control car oxidation" shows that control logic must be present to coordinate the monitoring, changing and replacing of solutions.It also derives the movement of the car body by interpreting the state of the oxidation bath and generating required signals such as "move car signal" to move the car body.
Continuous event flow : continuous event flow is one that is available over a period of time, such as the status of a device. Continuous event flows represent a situation or status that is either true or not.
Data Flow : a data flow represents the information generated by a source and used by another system function or terminator. On a data flow diagram the source of the data flow may be :
a process group : the function that generates the information within this group.
Continuous Data Flow : Data Flow that persists over a period of time is called as continuous data flow.The value is present over a period of time and may change during that time.
The figure shows a continuous data flow "solution strength" used by the process "monitor solution strength". Solution strength is the present strength of solution which is continuously present.
Dialogue data flow : dialogue data flow contains several data flows as an interface.At lowest level there can be two data flows in direct relation to each other, one causes the other to occur.
Comment : free-format comments may be added to the DFD to elucidate or stress any important points. Comments may be used to highlight any aliases,ties to previous or anticipated implementation.
Data flow diagram name ( DFD Name ) A data flow diagram has the same name as the corresponding process group show on the parent DFD.The context diagram is treated as a DFD with one process group.
Data flow diagram number ( DFD Number ) A data flow diagram has the same number as the process group it describes in more detail. The child diagram of the context diagram is numbered "0".
Data Process : A data process is a process that solely transforms data.Data processes may be continuous or descrete.A continuous data process may generate continuous or discrete event flows.A discrete data process cannot generate continuous event flows.
Data Store : Stores act as buffers between processes that are active at different times. A data store holds the data at rest.
A data store between two processes 'decouples' them ; a data flow between them 'synchronizes' them. In the figure the data store " solutions" is a collection of entity occurrence of all possible solutions used in the bathing of car bodies.
Dialogue event flow : Dialogue event flow is a packing of several event flows between two processes or between a process and a terminator.
Discrete access flow : A discrete access flow is an access to a store that takes place under the control of the system at a particular instant of time.In figure the process "Check solution is correct " accesses the store "solution in tank" to insure that the solution is correct for the car that is about to be bathed.
Discrete data flow : data flow that is variable for an instant of time is discrete data flow. A discrete data flow is transient and must be processed at the moment it occurs.
In the figure "solution change", generated by "change to new solution" represents the need to tell the operators that they must change to a certain solution.This is an example of discrete data flow.
Discrete event flow : event flow available for an instant of time is called as discrete event flow. If a control process detecting the discrete flow is not active at the time it occurs, the event flow will be lost.
Enable / Disable : This represents a process being enabled and disabled from a control process. An "E/D" represents the fact that the control process enables the process at one time and disables it subsequently.A process that is enabled will run whenever its stimulus occurs or run continuously until disabled.
Event Flow : An event flow represents the occurrence of an event ( discrete ) , or the state of something ( Continuous ).
Event store : An event store is a mechanism for storing events relating to resources until they can be used by a control process.When an event detector signals an event store ( rather than use a discrete event flow), it can respond ,or until the store is reinitialized.
Process : A process is a system function.It is either a data process , a control process , or a process group.It may be either continuous or discrete.
Process group : A process group represents a group of processes as a single icon on the diagram. This group may also contains internal stores and flows to accomplish its purpose -these are 'hidden' within the process group.
Process group are used to reduce the complexity of any one data flow diagram by combining related functions and naming the combinations for the general function that this group carries out.
In the figure "change to new solution" is a process group comprising processes "control solution change","determine new solution","detect empty tank", etc.
A process group is drawn on the diagram as a solid circle, it cannot be visually distinguished from a data process without looking at its specification.
Trigger : A prompt labeled "T" represents a trigger . The trigger will activate a discrete process , which will then "run to completion' and 'stop'.
In figure "check solution is correct " is triggered , as it will run in "zero time" and immediately reply with one of the two event flows "correct solution" or "incorrect solution".
Strengths and Weaknesses of DFDs
Strengths : DFD method is an object oriented method that allows to design systems using objects. It is widely used and promotes easy architecture and coding of a project. This method is also easy to learn.The symbols are few and simple and easy to translate.
Weaknesses : There aren't many weaknesses associated with this method. The DFD for large programs can be hard to translate and take a lot of time. Also, once the DFD is drawn for such a program, it becomes difficult to read and understand what is going on. The data flow can become confusing to the programmer in such an instance. Also, if the DFD is not drawn with the great amount of detail, then it is not useful to the programmer. Another disadvantage of using the DFD model is that the symbols used are not common to all DFDs. Different models use different symbols for the structure of a DFD.
7.2e DATA DICTIONARY
(ref :1. E. Yourdon (1989) : Modern Structured Analysis, Prentice-Hall , 2. T. De Marco (1991) : Introduction to System Analysis and Design. IInd edition, Prentice-Hall )
During the analysis and design of a system, huge amount of data is collected. If data is going to be referenced throughout the design, and several people are responsible for that design notation, then individuals who may not have initialized that data but will need to reference it need to know where it came from. Manually thumbing through several volumes of the data is not the most efficient way to find such information. To make sure that everyone can access it, it needs to be stored centrally in one document. A Data Dictionary fulfills that role.
Dictionary is basically a way of organizing the information, which is collected. This information enables us to work out the composition of the data, uniqueness and consistency of names and definitions of terms, and document them in dictionary which all team members can use. Ultimately it contain all information that enters, leaves and is transformed by the system, the policies surrounding that information, and description of all other objects and events of interest. This includes:
- data composition
- policies about data
- object and attribute descriptions
- event and state descriptions
- entity descriptions and relationship descriptions
- process descriptions
System aspects discovered during analysis may be lost unless they are not documented in dictionary, but if everything is documented in dictionary there are all chances that dictionary is huge and contains lots of data about data.
2 good ways for proper management are :
- Strict discipline: there should be a shared understanding between project members about what needs to be documented and how, who maintains and updates what-and severe penalties for anyone not sticking to it.
- Computerize it: with a project of any size, the data volume contained in the dictionary becomes too big to be handled by manual methods so it must be computerized to make the access quicker.
Concepts of notation
Notation helps to denote the basic kind of relationships between/among data items and elements, plus other information. These are some examples of data dictionary notation.
| NAME | SYMBOL | MEANING |
| Compostion | = | is composed of |
| Concatenation | + | and |
| Iteration | { } | multiple occuerneces of |
| Selection | [ | ] | choice1 or choice2 |
| Option | ( ) | may or may not be present |
| Discrete value | " " | the value of this variable |
| Comment | * * | additional information |
Ex:
1) entity 1 entity A = element B + element C + ( element D )
here it is shown that an entity A is made up of element B and element C and may or maynot contain element D.
2)
entity 1 travel claim = approval form + 2{ expense receipts }
it shows that travel claim contains 2 elements, approval form and set of expense receipts.
entity 2 expense receipts = travel receipt + {(incidental expendature)}
expense receipts consists of travel receipt and additionaly it could also consist of number of incidental expendature.
entity 3 travel receipt = [coach receipt | air receipt | rail receipt ]
* receipts not needed for a car travel *
travel receipt is needed for any form of travel undertaken with one exception that receipt is not needed if journey is
done by car.
entity 4 approval form = name + ref. no. + claim total
approval form has three parts, name of the person making the claim, the reference under which claim is made up and total being claimed.
entity 5 ref. no. = "B123"
reference number has a discrete value, the claim needs to be referenced as "B123".
entity 6 name = 2 {character }
a name must be 2 character long
entity 7 claim = 1{number}+"."+2{number}2
Claim figure must be made up of 1 or more numbers, a decimal point, and another 2 numbers to indicate fractions.
Problems with building and maintaining Data Dictionary
Imposters: items having the same name but multiple/different definitions. Giving a different (logical)name or new name can solve this problem.
Hybrid data: when definition has a hidden or mixed use. Using meaningful names and do the things right away without thinking of changing in future can avoid this very crucial problem.
Orphaned data: when nobody owns data, and nobody knows who created them. Author, data of entry and other "pedigree" information should be recorded.
There are , therefore, a number of ways in which the data dictionary will be impacted when designing the system. Definitions need to be put through a filtering process in order to make sure that rogue definitions do not go undetected. Regular analysis of data definitions is a time consuming but important and necessary exercise.Home
CHAPTER 9
IS APPLICATION MODELS IN INDUSTRY (TM)
An increase in company size results in an increase in information collection, processing and distribution. Hence it becomes necessary to handle many customer accounts and production records with many more interrelationships. In addition to increased information records, information needs and associated difficulties there arises the problem of delegation of authority and responsibilities.
Basic Information System
The basic functions of the company such as production, sales, finance and management functions will not change.
However the introduction of an MIS will facilitate fantastic improvement in the information communications network. The objective of developing or improving a management information system can be stated as below:
- To provide the type of information environment that will integrate the basic operating functions and
- To provide management with access to information relative to complex activities in decentralized organizations.
Also, as the company grows and becomes more complex much of the basic functions and information needs remain the same. Some of these internal information needs are shown as below:
1. Accounting Control
2. Plans and budgets
3. Payroll by hourly and salaried groups
4. Inventory of materials, in-process and finished goods
5. Sales by product, salesman , customer and Area
6. Purchasing records, vendors, commitments
7. Distribution-Transportation and warehousing
8. Production by product, customer, cost, overruns and backlog
9. Engineering-new products, schedules, equipment, costs
10. R&D etc. etc.
Although the current trend is to develop IS (with computer applications) in the areas other than the traditional areas, the bulk of information systems lie in the following categories :
Over time, a typical manufacturing company has developed the major information systems shown above. These systems are not separate and distinct; they connect interact and otherwise tie the subsystems of the organization together through the medium of information.
9.1 Financial Information System
The financial system is probably the most important single management information system, in the company, and in most companies it is the oldest and the best developed. These systems basically deal with large amounts of data and involve planning in the financial sector. However the budgeting function performed is wholly futuristic. Periodically the management approves a financial plan (the master budget) that assigns responsibility for maintaining incomes, investments and costs within standard limits. These plans are the basis for periodic financial reports and these reports are used by the system for exercising control and for futuristic planning.
The major operating systems of a company along with their respective functions (Shown in figure above) merge or integrate with the Accounting and Financial Information System to facilitate financial reporting and for management information for planning and control. Moreover, the financial system has a very significant impact on other systems when one considers that the ultimate common denominator of many operating decisions is the dollar. Perhaps, Billing (Invoice Preparation) is the most widely used data processing application among financial information systems.
9.2 Production/Operation System Model
From an operating standpoint, such a system is undoubtedly the most important in a manufacturing company. It crosses all subsystem boundaries and has an effect throughout the company. The production/ Operations system is concerned with information about the physical flow of goods or the production of goods and services. It covers such activities as production planning and control, inventory control and management, purchasing, distribution and transportation.
Because the quantities of data are so large and the timing of information so essential, the production/operations system is the most adaptable to automation and yields the largest benefits in terms of immediate solution of critical and costly problems. Although other applications (eg. decision-making, total system simulation) may offer greater potential, this functional area usually offers immediate pay-offs.
- Sales Analysis
- Engineering
- Inventory Control and Production Scheduling
- Production/Operations Facilities
- Purchasing
- Financial
- Sales and Distribution
Integration of subsystems through the information flow in the production/Operations System (Adapted from : Information systems for modern management by Murdick, Ross, Claggett)
9.3 Marketing Management Information System
The basic areas of the marketing function that lend themselves to improvement through information systems include:
(1) Forecasting/Sales planning
(2) Market research
(3) Advertising
(4) Operating and control information : Examples include sales reports and distribution cost reports. A marketing systems should also take into account of the necessity elsewhere in the organization concerning for information concerning market sales, and other internal information that affects decisions in other subsystems of the company.
Three types of marketing systems may be summarized as
1. Control systems
2. Planning systems and
3. Market research systems.
INPUTS OUTPUTS
Customer invoices Sales Profitability
Marketing budgets by product by product
Sales call reports product line product line
Cost reports customer class customer
Inventory reports cost center salesman
Accounts receivable region
Accounts payable salesman
Payroll (marketing)
Manufacturing costs
Annual Reports (customers, suppliers etc.)
Market Research
Analyses done by the system for periodic automated reporting :
-- Life cycle analysis
-- Marketing Personnel Analysis
-- Financial Analysis
Also OUTPUTS of the system include
-- SALES RECAP
-- RECORD SUMMARIES
-- TRANSACTION ANALYSIS
-- EXCEPTION INQUIRIES
(Adapted from : Information systems for modern management by Murdick, Ross, Claggett)
CHAPTER 10
STRATEGIES FOR IS (JMJ)
"The face of business is changing." "Businesses that do not become an e-business will not be around in five years."After watching the Superbowl this year, one might be will to accept these statements at face value. These statements lend themselves into being the mottoes of Silicon Valley, knowing these quotes come from Andy Grove chairman on Intel and also from a recent article in the Harvard Business Review by Hamel. It should obvious that an industry representative would make claims on the future that are much more hype than reality, but when these same statements are made in prestigious business journals, how does the business world react? Information Systems are the medium of this "evolution" in business and the proliferation of technologies is the catalyst IS change. The major shift coming is the impact of the internet-platform for doing business, which is currently being done on proprietary EDI systems. It is believed by businesses on the cutting edge of technology that the internet will be a leveling field for businesses that could not afford EDI in the past. EDI also was once claimed to be an evolutionary business step, but at an average cost of 50 million dollars for the system and in many cases no return on the investment , the future of EDI looks very grim, so say some of the successful practitioners of EDI. . In a recent joint study by the Economic Research Council and Oasig concluded that between eighty and ninety percent of EDI systems do not meet original performance goals . So while EDI is in its decline, is it prudent to embrace the new technologies of e-business? Forecasts call for a growth of e-business from 43 billion in 1998 to 1.3 trillion in 2002. The world has been wrapped many times over with internet connection lines and business already make up ninety percent of internet traffic.
There is little doubt that the internet is here to stay and it will have an impact on business, especially in the areas of information systems. If IS were about technology alone, its future would the very bright. Yet, information systems are more about the data and the people that use them to resolve problems. The technology is only a tool and not the answer to IS. Many software companies that do IS consulting and IS teams within the company may not agree with that philosophy, but software vendors have a tendency to be inflexible with their platforms and IS departments have a history of being rouge divisions within company structure .
A strategy to look at the future of IS, really needs to examine the past, and take a sober look at how IS in its many forms have fallen short of its promises. Steve Cardell and Neil Tiffin in an article in Industrial Management compiled six rules for putting together information systems.
1. Do not re-engineer and implement systems concurrently. From there studies the success rate is less than five percent.
2. Recognize that people fix things and information technology does not. They site Henry Ford as an example, his plants were able to process steel from iron ore to finished product in three days, in which he kept a few days inventory.
3. The business, not the IS department owns the system. This keeps costs under control and implementation on track.
4. Have an effective decision making forum. Managers and department heads are already busy, incorporating a new system that changes policy can be made very difficult if they are not kept up on what changes are taking place.
5. Configure only what the business needs.
6. When given a choice, choose flexibility
In reality strategies for IS come from studying data-flow with in an organization, and clearly defining the goals for the system and the users. If consultants are hired in they need to configure the system to fit the data flow of the business. Many EDI/ERP software companies had businesses reshape their data-flow, resulting in sub–optimal returns.
The new frontier of the internet and the information technology that drives it along with the heavy performances of high-tech industry market can be intoxicating to businesses, especially those IS illiterate. From the UH panel discussions, it becomes obvious EDI has work in only a few cases, there is no standard of IS software for the internet, everyone knows they must move to the internet, some of the companies invited to the panels do not have clear goals of how their organization should work with IS, and not one company was a the same level information technology; if this is the picture of the real world, the opening statements quoted are very risky, either very naïve or very arrogant. Quietly below the surface-hype of technology lies the ultimate future of IS, in the areas of data flow analysis. This is the one common thread for all the business that have succeed with any IS system no matter the decade it occurred in.
CHAPTER 11
E-Commerce and EDI
11.1 ELECTRONIC COMMERCE (TM)
Electronic commerce may be defined as the entire set of processes that support commercial activities on a network and involve information analysis. These activities spawn product information and display events, services, providers, consumers advertisers, support for transactions, brokering systems for a variety of services and actions (e.g., Finding certain products, finding cheaply priced products etc.), security of transactions, user authentication. etc.
[Ref. N.R Adam and Y. Yesha. “Electronic commerce: an Overview”]
There have been several similar electronic technologies in the past, for example Electronic data interchange (EDI) and Electronic funds tranfer (EFT) have been around for more than 20 years now. While many of these have electronic trading technologies have had radical effects within their own markets and created their fair share of publicity, none have attracted the level of hype or have been hailed as purveyors of economic transformation to the extent that e-commerce has in recent years. [ Ref. The Economist “The Economist Electronic commerce survey :In search of the perfect market”]
For example, EDI never gained the ubiquitous acceptance that was initially anticipated for it. High costs for initial investment, maintenance costs, or simply lack of preference by potential users kept EDI technologies from developing at a more rapid pace and has traditionally restricted its use to very large corporations.
Electronic commerce has experienced an explosion due to the convergence of these technology developments, the merging of the telecommunications and computing industries, and the business climate. [Ref. C Beam and A Segev “The rise of Electronic commerce :Contributions from three factors”] A ubiquitous digital infrastructure that provides an efficient means for communication and information sharing presents an extremely attractive new medium for electronic commerce and for the first time has the potential to deliver what the notion of EC has always implied. [D. Tapscott. “The Digital Economy: “Promise and peril in the age of networked intelligence”]
Electronic commerce involves issues (both technical and non technical) that are multi- disciplinary in nature. They are complex in nature and overlap significantly with each other. Technical research issues overlap with other technical research areas. For example, finding and filtering information is a fundamental requirement of an electronic commerce system but can be an equally important service for a digital library.
The figure below depicts the multidisciplinary nature of EC. As shown in the fig. The model is made up of several major components, beginning with the consumer who is interested in purchasing some goods electronically from some vendors whose product lines are represented in and are part of a global electronic marketplace.
The objectives of E-Commerce are several. Primarily they involve increasing the speed and efficiency of business transactions and processes, and improving customer service. Also EC should :
- Streamline procurement processes thereby cutting overall costs via a more competitive process
- Contribute to a decrease in the length of production cycles.
- Enable enterprises to conduct business with distant partners the same way they do with neighboring partners.
- Empower small businesses.
- Create new services and businesses.
- Help expand the horizon of participants.
In contrast to the emerging area of EC, EDI (Electronic data interchange) which has been around (in the same form) for 20 years now is the cause of positive and negative effects on industrial structures. A true cost benefit analysis of the effects can be difficult to assess, however; the costs become much easier to quantify than the benefits. Reduced personnel expense for data entry, paper and postage savings, and shortened receivable cycles are all quantifiable benefits, but the thousands to hundreds of thousands of dollars required to set up and maintain the implementation of traditional EDI needs to be justified with more significant benefits than these.
For an EDI implementation to be successful, it needs to be the direct cause of improved productivity and internal operations, create closer customer vendor relations, provide a competitive advantage in the marketplace, and open up the procurement process. Historically this has not been the case for two reasons :The high cost involved with EDI, especially for small to medium-sized enterprises(SMEs), and what we refer to as standard issues. (Ref. Electronic commerce; Nabil Adam, Oktay Dogramaci et al.)
E-C applications in Supply-Chain and manufacturing
Another area where EC applications facilitate improvement is supply chain management. The objective of an electronic commerce strategy is to provide purchasing managers with better control over their companies’ purchasing habits and relationships with suppliers]
Continuous improvement of an organization’s supply-chain is directly related to its performance, and EC applications are being used in procurement processes more and more frequently to this end. Changes in the supply chain are closely related to inter-business retail processes. The advantages of EC in supply-chain management include access to a wide range of suppliers and effective use of organizational resources that are essential for implementing just-in-time (JIT) manufacturing systems.
.[Ref. C Curtis; “Getting on to the e-Commerce supply chain ‘Just in time’ Internet week Sept. 1997]
These automated systems provide new types of information for businesses that implement them. Among the enhanced capabilities for managers are improved sales forecasts, more accurate balance sheets, and closer relationships with customers using a new interface. Direct communications between suppliers and customers streamlines the supply chain and delivers new relevant information to manufacturers in real-time.
For one example of how businesses are accomplishing these goals, craig (in internet Week Nov. 1997) describes a joint venture between SAP and Digital Equipment Co. to keep vending machines filled to demand with a web-based EDI system. An embedded computer in the vending machines is connected to the internet, and each time a product is purchased a message is sent to the supplier. This gives suppliers crucial information about their distribution channels in real-time, and removes the requirement for vending machine operators to use non standard proprietary software that accomplished this task in the past.
11.2 ELECTRONIC DATA INTERCHANGE (EDI) (MR)
(Source : EDI ebook, at editraining.com)
Electronic Data Interchange or EDI is the electronic exchange of business documents from one company’s computer to another’s computer in nationally standard structured data formats.
Using EDI to exchange business documents eliminates the rekeying of the data, resulting in more accurate data. In EDI, data necessary for conducting business is transmitted directly into a system without human intervention. We can transmit and receive EDI documents with companies such as banks, railroads, customers and suppliers. The companies who send and receive EDI with are referred to as trading partners.
For many years business data has been exchanged electronically on tapes, disks , diskettes and over direct computer to computer hookups. Companies realized replacing the paper used in business transactions with electronic communication saved both money and time
Customers and suppliers were interested in sending and receiving electronic documents; however, each company had different documents need and different computer and communication medium. The effort to maintain different document formats and different communications hookups became time consuming and costly. Electronic transactions started becoming standardize. Different standards for different industries still exist. The Accredited Standards Committee (ASC) X12 of the ANSI was created to support the national standards of EDI. Transaction sets (standard business transaction formats) are developed and maintained by the ASC X12.
Most of Industries use subset of the X12 standards. Following are some major industries that use subsets :
AFPA Paper Industry
CIDX Chemical Industry
WINS Warehouse Industry
VICS Retail Industry
UN/EDIFACT Standards are used internationally.
EDI Data Structure
Individual electronic transmission between trading partners is grouped in an electronic envelope similar to putting paper documents into paper envelopes. The electronic envelope specifies who is sending and who is receiving the documents. Within each electronic envelope is a collection of documents of the same type, this is called a functional group. An example of the functional group is a collection of invoices. You can group several invoices together and send them in a functional group in EDI.
Documents (purchase orders, invoices..) are referred to as transaction sets in ANSI X 12 standards and messages in UN/EDIFACT standards. There are hundreds of document types defined by EDI standards.
A document contains segments that are logical groups of information. Each segment is preceded by a segment identifier and terminated by a segment separator. A segment is made up of data elements. This is where the information is stored.
How Does EDI Work?
EDI involves three functions within each computer system:
1) Application Interface System.
2) EDI Software
3) Communications Handler
Application Interface System
- Processes the data to be sent to, or received from, the trading partner.
- Moves electronic transactions to or from the application system.
- Programs separate and deliver inbound transactions to the application systems.
- 4. Delivers inbound transactions to the applications systems and gathers transactions from the application systems for outbound transmission.
EDI Software
- 1. Manipulates and routes data between the application system and the communications handler.
- 2. Translates Business documents into and out of the X12 formats.
- 3. Creates Functional Acknowledgments (EDI transaction that notifies the trading partner that an electronic document was received).
- 4. Verifies the identity of trading partners.
- 5. Validates the transactions by checking a master file against the information transmitted.
Communications Handler
- Transmits data to and from the trading partner through a value-added network.
- Protects against transmission errors or interruptions.
Example of EDI Process:
This example shows the process of a shipment notice from the manufacturer to the customer. These are various steps involved in process:
1. The data is extracted from the shipment and database.
2. The data is translated by the EDI software into a standard X12 EDI shipment notice format.
3. The EDI shipment notice is transmitted through a Value Added Network (VAN) to the company.
4. The company receives the EDI shipment notice.
5. The EDI shipment notice is translated into a format that can be used to update the database of the company.
11.3 EDI and E-Commerce (MR)
(Source : Article by G.Berton Latamore, Apics,February 1999,No.2)
- Although EDI has been the traditional approach to automating business transactions between trading partners, e-commerce, using Java applets embedded in Internet-enabled applications, is coming on strong.
- E-commerce offers several advantages over EDI. The initial investment in technology is much less. For smaller companies with lower trading volumes, the internet costs much less than a VAN. Internet reaches everyone in the supply chain, supports near real-time messaging, and supports both machine-to-machine and human-to-machine transactions.
- EDI has advantages for larger manufacturers that must automate complex transactions among a large community of suppliers. It provides a standard way to format key transaction data and provides a complete set of messages, including acknowledgements.
- EDI also includes built-in security, while the Internet is still a very insecure environment.
- E-commerce sites focused on the supply chain have been designed to extend electronic commerce to supply chain members that have not invested in EDI, rather than replacing existing EDI sites. Most experts expect this pattern to continue and advise manufacturers with EDI systems to consider adding e-commerce front ends to allow smaller suppliers or customers to communicate directly with their existing infrastructure.
-
However, experts caution that EDI and e-commerce are not necessarily antagonistic and agree most companies need a combination both to effectively reach their entire supply chain.
E-Commerce Advantages Where EDI Excels Less expensive and easier to implement for simple transactions bteween two trading partners. However becomes expensive and complex when trying to support sets of complex transactions among large groups of trading partners. Provides a complete, integrated package to support transactions, including receipts showing that transactions were received; e-commerce only provides a template from which each form must be created and each response programmed Supports near real-time transactions. Handles a much wider range of transaction types and can be used for any kind of transaction between trading partners. Provides a complete security package; e-commerce has no built-in security and requires that a suite of separate security applications be custom integrated. Supports both machine-to-machine and man-to-machine transactions; EDI only does machine-to-machine, making it an impractical answer for handling specialty or occasional orders. VANs are very secure; the Internet, by design, is insecure. Reaches everyone over the Internet; EDI only reaches trading partners who can afford connectivity to the VAN of choice. Optimized for large volumes of transactions processed on large servers or mainframes; e-commerce is most successful in low-volume environments running on PCs or smaller servers.
- INTERFACES
12.1 Computer Assembly
12.2 Software Loading
12.3 Distribution and Transportation System
GlOSSARY OF TERMS
ACQUISITION COSTS: these costs include the price of the items, the shopping time, the paper work, expediting (emergency buy, down time), mistakes (returns, rejects, quantity errors; this will generate expediting costs), and the price for internal handling (receiving and storing).
BREAK-BULK CARGO: Cargo, which is, shipped a unit (i.e. Palletized cargo, boxed Cargo, large machinery, trucks and pre-slung cargo).
BULK CARGO: Loose cargo that is loaded directly into a ship's hold.
BULK CARRIER: There are two types of bulk carrier, the dry-bulk carrier and the liquid-bulk carrier better known as a tanker. Bulk cargo is a shipment such as oil, grain, or ore which is not packaged, bundled, bottled, or otherwise packed and is loaded without counting or marking.
BUSINESS PROCESS (BP) : A set of logically related tasks performed to achieve a defined business outcome.
CARRIER(S) CONTAINER(S)/SHIPPER(S) CONTAINER(S): The term Carrier(s) Container(s) or Shipper(s) Container(s) means containers over which the carrier or the shipper has control either by ownership or by the acquisition thereof under lease or rental from container companies or container suppliers or from similar sources. Carriers are prohibited from purchasing, leasing or renting shipper owned containers.
CHANGE ANALYSIS: Study of suitable changes of the activities of an enterprise in concrete situation
CORRUGATED CASES: Built like a sandwich cardboard - characteristic arches of wavy "fluting" lying between two pieces of smooth board on the outside.
CONTAINER: The term container means a single rigid, non-disposable dry cargo, insulated, temperature controlled flatrack, vehicle rack portable liquid tank, or open top container without wheels or bogies attached, having not less than 350 cubic feet capacity, having a closure or permanently hinged door that allows ready access to the cargo (closure or permanently hinged door not applicable to flatrack vehicle rack or portable liquid tank).
CONTAINER SHIP: Ocean going ship designed to carry containers both internally and on deck. Some are self-sustaining.
CONTAINERIZATION: Concept for the ultimate unitizing of cargo used by both steamship lines and air cargo lines. Containers allow a greater amount of cargo protection from weather, damage, and theft.
DATA: Raw information representing events occurring in the organization before they are organized into an understandable and useful form for humans
DATA DICTIONARY: A way of organizing information, which is collected. This information enables one to work out the composition of the data, uniqueness and consistency of names and definitions of terms, and document them in dictionary which all team members can use
DATA FLOW: Data flow on context diagram either represents information produced within or outside the system which is used by outside world or by the system itself
DATA FLOW DIAGRAM: An important technique for modeling high level detail in a process within a system. They highlight the functions of the system and how they use stored information and transfer information between each other.
DATA-ORIENTED WORK: Refers to the development parts whose purpose is to design technical solutions to this specification.
DISTRIBUTION CHANNELS: Methods by which distribution get products to market.
EDI: Electronic Data Interchange; Proprietary systems by which companies share information.
END-USERS: Customers that are served by distribution.
ENTITIES RELATIOINSHIP DIAGRAMS (ERD): A semantic modeling tool used to identify and organize information and to model particular roles of importance to the enterprise and relationships between them
ENTITIES: A class of real world thing whose role of interaction with the enterprise is well defined.
INFORMATION: A derivative from meaningful interpretation of data.
INFORMATION SYSTEM: A set of interrelated components that collect (or retrieve), process, store and distribute information to support decision making and control in an organization.
INFROMATION TECNOLOGY (IT) : This includes the capabilities offered by computers, Software and telecom. The current media by which information is transferred.
HOLDING COSTS: are the interest costs, the storage cost, the control cost (shipping, transportation, security), taxes, insurance, and the shrinkage cost (shipped short or long, stolen, obsolescence).
HUB: A central location to which traffic from many cities is directed and from which traffic is fed to other areas.
MANAGEMENT INFORMATION SYSTEMS (MIS): A division in corporate structure that creates and maintains IS for the management levels of an organization.
OFFICE AUTOMATION SYSTEMS (OAS): Serves the knowledge level of an organization.
PALLET: Load carrying platform to which loose cargo is secured before placing aboard the aircraft.
PERISHABLES: Any cargo that loses considerable value if it is delayed in transportation (Usually refers to fresh fruit and vegetables).
PROBLEM-ORIENTED WORK: In information systems development, refers to the development parts whose purpose is to specify what the information systems will do.
STRADIS (Structured Analysis And Design of Information Systems): follows the Top-down approach (functional decomposition) for analyzing processes./
TOTAL PROCUREMENT COSTS: are the holding costs and the acquisition costs.
TRANSACTION: A performance or management of a business. In the context of distribution, it is all the interactions between manufacturing, distribution and end-users.
TRANSACTION PROCESSING SYSTEMS (TPS): Serves the operational level of an organization.
UNITISATION: The packing of single or multiple consignments into ULDs or pallets.
USER: One who would be accessing an IS interface in order to gain a knowledge, to apply to a decision making process.
- 11 次浏览