Materi Analisa Perancangan System

Case study

1. Gambarkan sistem secara umum (general) Dalam penggambaran sistem tersebut, sebutkan siapa saja user/actor/sistem lain yang berperan di dalamnya. Simpulkan permasalahan apa saja yang terjadi dalam sistem tersebut. (see General Background.docx)

 Interview  clarification.  Forms and files  users’ agreement,

 Data flow diagram rules The analyst needs to be aware of some rules which apply to DFDs. These rules exist not to make life difficult, but to ensure consistency in diagramming.  Process rules Processes must have both inputs and outputs. If there is no input, but there is an output, then the output has been created from thin air. Sadly, this does not happen. If there is an input but no output, then the process is a waste of everyone’s time and should be scrapped.  Data flow rules Data flows must go through a process box. It is not allowed to have a data flow going directly from an external entity to a data store, for example.  External entity rules The label must be a noun, e.g. SUPPLIER.  Data store rules A data flow into a data store means update the data store. A data flow from a data store means retrieve data from the data store. See – Materi APS – Pengenalan DFD.pptx

 The main tasks to be completed, in order, are: 1 Draw a context diagram. 2 Draw a document flow diagram. 3 Draw a top-level data flow diagram. 4 Draw lower level data flow diagrams.

 Our current physical DFDs are now complete. They should give us a picture of what the Medical Centre currently does. They should be understandable and be useful as a communications tool with the user. However, there are limitations with DFDs. They don’t do everything (which is why we need other techniques). Here are a few limitations:  They don’t show us how the data is structured.  They don’t show the effect of time or sequence.  They may not help communicate with the user – they may be too complex.  They take a long time to draw and redraw.  They may never be complete While these limitations are real enough, the experienced analyst can use DFDs as a useful tool and not allow the limitations to become a problem.

1. Buat General Background dari sistem yang anda pilih. 2. Buat Problem/Requirements Catalouge 3. Buat Daftar External Entiti 4. Gambar Context Diagram 5. Buat Daftar Internal Entiti 6. Gambar Dokumen Flow Diagram 7. Gambar Top Level Data Flow Diagram 8. Gambar DFD Level 1 dan DFD level 2 masing – masing proses.

 Entitas  Things/ Sesuatu tempat informasi berada ▪ People, customer, member, student ▪ Object, product, recipes,

 Bits of Data yang menerangkan Entitas  Entitas MEMBER  Atribut

 Cara untuk mengidentifikasi sesuatu  Contoh orang, untuk mengidentifikasi digunakan NAMA  Primary Key, Key yang unik  MEMBER, MEMBERSHIP NUMBER  STUDENT, NRP  PATIENT, PATIENT NUMBER

 Hubungan antar Entitas

1.Data entitas yang ada pada sistem 2.Masing-masing entitas dibuatkan atributnya dan contoh isiannya 3. Memilih Key 4. Menentukan relasi dan Tipe relasinya 5. Mencocokkan datastore DFD dengan diagram entitas 6. Membuat ERD.

 List Data Stores  Produce the logical data store/entity cross-reference  Remove time dependencies  Remove names and departments from the process boxes  Change processes so that they describe what is done to the data  Remove any physical references from the process box  Make sure that the data flows refer to logical items of data  Data flows between processes should be removed

1.Identifikasi alternative solusi untuk menjawab hasil analisis 2.Menentukan alternative solusi yang dipilih

Software Design

INPUT/ OUTPUT DESIGN

1.Buat Analisa Data System 2.Logikalisasi 3.Buat Business System Options 4.Buat Elementary process descriptions 5.Buat Decision Tree / Pseudo-Code / Structured English 6.Buat Design Input / Output