Technical Design:Information system design

By -

9.1 Introduction

This chapter is concerned with building a bridge between the problem situation requirements, as reflected in the UML information models, and an information system implementation. It is apposite to view technical design as a bridge, rather than a transition, since the analogy of a bridge suggests a bi-directional movement between information system requirements and implementation in software.

Developing Web Information Systems-0090

9.2 Information system design

The metaphor of time's arrow suggests a one-way path from requirements to design to implementation. Feedback loops and arrows can be added to give the impression of iteration, but this is a weak depiction of the complex relationship between requirements and design. The idea of mediation in IS development means that the social and technical aspects are mangled together and whether we like it or not, technical design should not and cannot be reduced to an exercise in techno-rationality. The technical design process must be considered within the context of organizational analysis and work design, and not simply as a scientistic refinement of the requirements specification. However, despite this caveat, in order to illustrate technical design in a clear way we will work within a techno-rational paradigm in this chapter.

Developing Web Information Systems-0091

Analysis is often defined as the 'what' of IS development, being concerned with what the system can do, e.g., find available seats, process a ticket sale transaction, rather than how it achieves this end. In moving to design we are more concerned with 'how' the ends will be achieved in software terms. In practice the boundaries between 'what' and 'how' are blurred and analysis and design are difficult to disentangle. With traditional approaches to IS development, such as SSADM (Structured Systems Analysis and Design Method), there are clear cut-off points where the deliverables from one stage are signed-off, ready to move to the next stage where new notations and techniques are introduced. For many developers, the appeal of OO and UML is that the developer is not forced into making a hard, once-and-for-all, break between analysis and design. With UML the principal diagrams are elaborated in greater detail until they become sufficiently detailed to become an executable  specification, or for a human programmer to implement them by hand in program code. In the UML approach design is not a one-off activity. It is an iterative process of elaboration of detail, moving back and forwards between a logical, implementation-independent design and a physical, implementation-specific design (figure 9.2). The design process also entails a movement between a high level system or architectural design and the detailed design of software components, such as the individual classes and operations (figure 9.2).

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

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

The Revenue Cycle:Manual Systems

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

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more