Bab 6 Pendekatan Tradisional untuk Kebutuhan Sistem

Diterjemahkan oleh: Komarudin Tasdik

http://komarudintasdik.wordpress.com

Slide 1: Judul

Slide 2: Tujuan Pembelajaran

v   Menjelaskan bagaimana pendekatan tradisional dan pendekatan berorientasi objek berbeda ketika memodelkan detil use case

v   Membuat daftar komponen sistem tradisional dan simbol-simbol yang merepresentasikannya pada data flow diagram

v   Mendeskripsikan bagaimana data flow diagram dapat menampilkan sistem pada berbagai level abstraksi

Slide 3: Tujuan Pembelajaran (lanjutan)

v   Mengembangkan data flow diagram, definisi elemen data, definisi data store, dan deskripsi proses

v   Membaca dan menginterpretasikan model-model Information Engineering yang dapat disatukan dalam analisis terstruktur tradisional

v   Mengembangkan tabel-tabel untuk menampilkan distribusi pemrosesan dan data access melintasi lokasi-lokasi sistem.

Slide 4: Gambaran Umum

v   Sistem apa yang berjalan dan event apa yang terjadi—aktivitas-aktivitas dan interaksi-interaksi (use case)

v   Pendekatan terstruktur tradisional untuk merepresentasikan beberapa aktivitas dan interaksi

v   Diagram dan model lainnya dari pendekatan tradisional

v   Contoh RMO customer support system menampilkan bagaimana tiap model terelasi

v   Bagaimana pendekatan dan model tradisional dan IE dapat digunakan bersama-sama untuk mendeskripsikan system

Slide 5: Pendekatan Tradisional dengan Pendekatan berorientasi Objek

Pendekatan Tradisional:

v   Sistem merupakan koleksi proses

v   Proses berinteraksi dengan entitas data

v   Proses menerima input dan menghasilkan output

Pendekatan Berorientasi Objek:

v   Sistem adalah koleksi objek yang berinterkasi

v   Objek berinteraksi denga orang dan masing-masing objek

v   Objek mengirim dan merespon pesan

Slide 6: Pendekatan Tradisional dalam Bab ini

Lihat slide aslinya

Slide 7: Data Flow Diagrams (DFDs)

v   Model sistem grafis yang menampilkan semua kebutuhan utama untuk sebuah IS dalam satu diagram

• Inputs/outputs
• Processes
• Data storage

v   Mudah dibaca dan dipahami dengan pelatihan minimal

Slide 8: Data Flow Diagram Symbols

Untuk gambar simbol lihat slide aslinya

v   Proses: instruksi langkah demi langkah yang diikuti yang mentransformasikan input ke dalam output (komputer atau orang atau keduanya mengerjakan suatu tugas)

v   Data Flow: Data yang mengalir dari tempat ke tempat, seperti input atau output untuk suatu proses

v   External agent: sumber atau tujuan data di luar system

v   Data Store: data at rest, disimpan untuk penggunaan selanjutnya. Biasanya sesuai dengan entitas data pada entity-relationship diagram

v   Real-Time link: komunikasi sebelum dan sesudahnya antar agen eksternal dan proses sebagai proses yang sedang mengeksekusi (contohnya verifikasi kartu kredit)

Slide 9: DFD Fragment Showing Use Case Look up item availability from the RMO

Lihat slide aslinya

Slide 10: DFD Integrates Event Table and ERD

Lihat slide aslinya

Slide 11: DFD dan Level Abstraksi

v   Data flow diagrams (DFDs) didekomposisi ke dalam diagram tambahan untuk menyajikan berbagai level detil

v   Diagram level lebih tinggi menyediakan pandangan umum tentang sistem

v   Diagram level lebih rendah menyajikan pandangan detil tentang sistem

v   Membedakan pandangan yang disebut level abstraksi

Slide 12: Layers of DFD Abstraction for Course Registration System

Lihat slide aslinya

Slide 13: Context Diagrams

v   DFD yang meringkas semua aktivitas pemrosesan untuk sistem atau subsistem

v   Pandangan level yang sangat tinggi (sangat abstrak) tentang sistem

v   Menampilkan batasan-batasan sistem

v   Skup sistem yang direpresentasikan oleh proses tunggal, agen eksternal dan semua data yang mengalir ke dalam dan ke luar system

Slide 14: DFD Fragments

v   Dibuat untuk masing-masing use case dalam event table

v   Merepresentasikan respon sistem terhadap satu event di dalam simbol proses tunggal

v   Self-contained models

v   Fokus perhatian pada bagian tunggal sistem

v   Hanya menampilkan data stores yang dibutuhkan dalam use case

Slide 15: Three Separate DFD Fragments for Course Registration System

Lihat slide aslinya

Slide 16: Event-Partitioned System Model

v   DFD untuk memodelkan kebutuhan sistem yang menggunakan proses tunggal untuk masing-masing use case/activity dalam sistem atau subsistem

v   Mengkombinasikan semua DFD fragment bersama-sama untuk menampilkan dekomposisi context-level diagram

v   Kadang-kadang disebut “diagram 0”

v   Digunakan terutama sebagai tool presentasi

v   Didekomposisi ke dalam DFD fragments yang lebih detil

Slide 17: Combining DFD Fragments to Create Event- Partitioned System Model

Lihat slide aslinya

Slide 18: Context Diagram for RMO Customer Support System

Lihat slide aslinya

Slide 19: RMO Subsystems and Use Cases/Activities from Event Table

Subsistem entri pesanan

Melihat keberadaan produk

Membuat order baru

Mengupdate pesanan

Membuat laporan ringkas pesanan

Membuat laporan ringkas transaksi

Subsistem pemenuhan pesanan

Melihat status pesanan

Mencatat pemenuhan pesanan

Mencatat pesanan yang kembali

Membuat pengembalian pesanan

Membuat laporan ringkas pemenuhan pesanan

Subsistem pemeliharaan pelanggan

Menyediakan informasi katalog

Memproduksi laporan aktivitas pelanggan yang prospektif

Mengupdate account pelanggan

Mendistribusikan paket promosi

Membuat penyesuaian harga pelanggan

Membuat laporan penyesuaian pelanggan

Subsistem pemeliharaan katalog

Mengupdate katalog

Membuat promosi produk special

Membuat katalof baru

Membuat laporang aktivitas katalog

Slide 20: Context Diagram for RMO Order-Entry Subsystem

Lihat slide aslinya

Slide 21: Five Separate DFD Fragments for RMO Order-Entry Subsystem

Lihat slide aslinya

Slide 22: Dekomposisi DFD Fragments

v   Banyak sekali DFD fragment yang dapat dideskripsikan lebih jauh menggunakan bahasa Inggris terstruktur

v   Kadang-kadang DFD fragments harus dibuat diagram yang lebih detil

v   Didekomposisi ke dalam subproses dalam DFD detil

v   Skema penomoran DFD

• Dekomposisi hirarkis

Ø      DFD Fragment 2 didekomposisi ke dalam Diagram 2

Ø      Diagram 2 memiliki proses 2.1, 2.2, 2.3, 2.4

Slide 23: Detailed DFD for Create new order DFD Fragment

Lihat slide aslinya

Slide 24: DFD Fisik dan Logis

v   Model logis

• Mengasumsikan implementasi dalam teknologi sempurna
• Jangan menceritakan bagaimana sistem diimplementasikan

v   Model fisik

• Mendeskripsikan asumsi-asumsi tentang implementasi teknologi
• Dikembangkan dalam langkah analisis terakhir atau dalam desain awal

Slide 25: Physical DFD for Scheduling Courses

Lihat slide aslinya

Slide 26: Mengevaluasi Kualitas DFD

v   Dapat dibaca

v   Konsisten dan seimbang secara internal

v   Dengan akurat merepresentasikan kebutuhan sistem

v   Mereduksi informasi overload-rule 7+/- 2

• DFD tunggal tidak harus memiliki lebih dari 7 +/-2 proses
• Tidak lebih dari 7+/- 2 aliran data yang harus masuk atau meninggalkan proses atau data store dalam DFD tunggal

v   Meminimalisir jumlah interface yang dibutuhkan

Slide 27: Permasalahan Konsistensi Aliran Data

v   Perbedaan dalam konten aliran data di antara proses dan dekomposisi prosesnya

v   Data outflows tanpa inflows yang sesuai

v   Data inflows tanpa outflows yang sesuai

v   Hasil-hasil dalam DFD yang tidak sesuai

Slide 28: Aturan Konsistensi

v   Semua data yang mengalir ke dalam sebuah proses haru

• Mengalir keluar proses, atau
• Digunakan untuk menghasilkan data yang mengalir keluar proses

v   Semua data yang mengalir keluar proses harus

• Telah mengalir ke dalam proses, atau
• Telah dihasilkan dari data yang telah mengalir ke dalam proses

Slide 29: Unnecessary Data Input: Black Hole

Lihat slide aslinya

Slide 30: Process with Impossible Data Output: A Miracle

Lihat slide aslinya

Slide 31: Process with Unnecessary Data Input

Lihat slide aslinya

Slide 32: Process with Impossible Data Output

Lihat slide aslinya

Slide 33: Dokumentasi Komponen DFD

v   Proses-proses level sangat rendah harus dideskripsikan secara detil

v   Konten aliran data harus dideskripsikan

v   Data stores harus dideskripsikan dalam istilah elemen-elemen data

v   Tiap elemen data harus dideskripsikan

v   Berbagai pilihan untuk keberadaan definisi proses

Slide 34: Bahasa Inggris yang Terstruktur

v   Metode spesifikasi proses penulisan

v   Mengkombinasikan teknik-teknik pemrograman terstruktur dengan bahasa Inggris naratif

v   Well-suited untuk proses-proses sequensial panjang atau logika kontrol sederhana (loop tunggal atau if-then-else)

v   Ill-suited untuk logika keputusan kompleks atau sedikit (atau tidak ada) langkah-langkah pemrosesan sekuensial

Slide 35: Contoh Bahasa Inggris Terstruktur

Lihat slide aslinya

Slide 36: Process 2.1 and Structured English Process Description

Lihat slide aslinya

Slide 37: Tabel Keputusan dan Pohon Keputusan

v   Dapat meringkas logika keputusan kompleks lebih baik daripada bahasa Inggris terstruktur

v   Logika incorporate ke dalam struktur tabel atau pohon untuk membuat deskripsi lebi dapat dibaca

Lihat bentuk tabelnya di slide asli

Slide 38: Decision Tree for Calculating Shipping Charges

Lihat slide aslinya

Slide 39: Definisi Aliran Data

v   Deksripsi tekstual tentang konten aliran data dan struktur internal

v   Hamper sama dengan atribut entitas data yang termasuk dalam ERD plus nilai komputasi

v   Algebraic notion describes data elements on data flow plus data structure

v   Notasi aljabar mendeskripsikn elemen-elemen data pada aliran data plus struktur data

New-Order = Customer-Name + Customer-Address + Credit-Card-Information + {Item-Number + Quantity}

Slide 40: Data Flow Definition for RMO Products and Items Control Break Report

Lihat slide aslinya

Slide 41: Definisi Elemen Data

v   Deskripsi tipe data

• String, integer, floating point, Boolean
• Kadang-kadang deskripsi tertulis yang sangat spesifik

v   Panjang elemen

v   Nilai-nilai maksimum dan minimum

v   Kamus data—tempat penyimpanan untuk definisi aliran data, data store dan elemen data

Slide 42: Data Element Definition Examples

Lihat slide aslinya

Slide 43: Components of a Traditional Analysis Model

Lihat slide aslinya

Slide 44: Model Information Engineering

v   Fokus pada perencanaan strategis, aplikasi perusahaan, dan kebutuhan data dari sistem baru

v   Berbagi fitur dengan metodologi pengembangan sistem terstruktur

v   Dikembangkan oleh James Martin di awal 1980

v   Digagas agar lebih teliti dan lengkap daripada pendekatan terstruktur

Slide 45: Information Engineering System Development Life Cycle Phases

Lihat slide aslinya

Slide 46: Dekomposisi Proses dan Model Dependensi

v   Model proses IE menampilkan tiga jenis informasi

• Dekomposisi proses-proses ke dalam proses-proses lain
• Relasi dependensi antar proses
• Logika pemrosesan internal

v   Diagram dekomposisi proses—merepresentasikan relasi hirarkis antar proses pada level abstraksi yang berbeda

v   Model dependensi proses—mendeskripsikan ordering proses dan interaksi dengan entitas yang disimpan

Slide 47: Process Decomposition Diagram for RMO

Lihat slide aslinya

Slide 48: Process Dependency Diagram

Lihat slide aslinya

Slide 49: Lokasi dan Komunikasi melalui Jaringan

v   Informasi logis digunakan selama analisis

• Jumlah lokasi pengguna
• Pemrosesan dan kebutuhan data access pada berbagai lokasi
• Volume dan timing pemrosesan dan permintaan data access

v   Harus membuat keputusan desain inisial seperti

• Distribusi sistem kmputer, perangkat lunak aplikasi, komponen basis data, kapasitas jaringan

Slide 50: Mengumpulkan Informasi Lokasi

v   Mengidentifikasi lokasi di mana pekerjaan dikerjakan

v   Menggambar diagram lokasi

v   Mendaftar fungsi-fungsi yang dilakukan para pengguna di tiap lokasi

v   Membangun matrols lokasi aktivitas

• Baris adalah aktivitas sistem dari event table
• Kolom adalah lokasi fisik

v   Membangun matrik data aktivitas (CRUD)

• Membuat, membaca, mengupdate dan menghapus CRUD

Slide 51: RMO Activity-Location Matrix

Lihat slide aslinya

Slide 52: RMO Activity-Data Matrix (CRUD)

Lihat slide aslinya

Slide 53: Ringkasan

v   Data flow diagrams (DFDs) digunakan dalam mengkombinasikan event table dan entity-relationship diagram (ERD) untuk memodelkan kebutuhan sistem

v   Sistem model DFD sebagai rangkaian proses, aliran data, agen eksternal, dan data store

v   DFD mudah dibaca—secara grafis merepresentasikan fitur kunci sistem yang menggunakan kumpulan kecil simbol

v   Beberapa jenis DFD— context diagrams, DFD fragments, subsystem DFDs, event-partitioned DFDs, dan detailed process DFDs

Slide 54: Ringkasan (lanjutan)

v   Tiap proses, aliran data, dan data store membutuhkan definisi detil

v   Analis mungkin menentukan proses-proses sebagai spesifikasi proses bahasa Inggris terstruktur, tabel keputusan, pohon keputusan, atau DFD proses detil

v   DFD dekomposisi proses detil digunakan ketika kompleksitas proses internal itu besar

v   Aliran data ditentukan dengan elemen data komponen dan struktur internalnya (notasi aljabar)

Slide 55: Ringkasan (lanjutan)

v   Model dari IE mungken mensuplemen DFD

• Diagram dekomposisi proses (bagaimana proses pada berbagai level DFD direlasikan)
• Diagram dependensi proses (menegaskan interaksi dengan stored entities)
• Location diagram (where system is used)
• Diagram lokasi (di mana sistem digunakan)
• Matrik lokasi aktivitas (proses mana yang diimplementasikan pada lokasi yang mana)
• Matrik data aktivitas (atau CRUD) (di mana data digunakan)

***

Original Title: Systems Analysis and Design in a Changing World, Fourth Edition

Chapter 6 The Traditional Approach to Requirements

Source: Materi Mata Kuliah S2 Ilmu Komputer Institut Pertanian Bogor (IPB) 2010/2011

Bab 5 Memodelkan Kebutuhan Sistem

Diterjemahkan oleh: Komarudin Tasdik

http://komarudintasdik.wordpress.com

Slide 1: Judul

Slide 2: Tujuan Pembelajaran

v   Menjelaskan beberapa alasan untuk membuat model-model sistem informasi

v   Mendeskripsikan tiga jenis model dan daftar beberapa model spesifik yang digunakan untuk analisis dan desain

v   Menjelaskan bagaimana events bisa digunakan untuk mendefinisikan aktivitas dan use cases

v   Mengidentifikasi dan menganalisis events yang berhubungan dengan repon-respon sistem

Slide 3: Tujuan Pembelajaran (lanjutan)

v   Menjelaskan bagaimana konsep “thing” dalam domain masalah juga menentukan kebutuhan-kebutuhan

v   Menjelaskan persamaan dan perbedaan antara entitas dan objek data

v   Mengidentifikasi dan menganalisis entitas-entitas data dan domain classes yang dibutuhkan dalam sistem

v   Membaca, menginterpretasi, dan membuat entity-relationship diagram

v   Membaca, menginterpretasikan, dan membuat class diagram

Slide 4: Gambaran Umum

v   Mendokumentasikan kebutuhan fungsional dengan membuat model-model

v   Model-model dibuat selama aktivitas fase analisis—Menetapkan kebutuhan system

v   Dua konsep membantu mengidentifikasi kebutuhan fungsional dalam pendekatan tradisional dan pendekatan berorientasi objek

• Events yang mentrigger use cases
• Things dalam domain kerja pengguna

v

Slide 5: Model dan Pemodelan

v   Analis mendeskripsikan kebutuhan siste informasi menggunakan kumpulan model

v   Sistem yang kompleks membutuhkan lebih dari satu tipe model

v   Model merepresentasikan suatu aspek dari sistem yang sedang dibangun

v   Proses pembuatan model membantu analis mengklarifikasi dan memperhalus desain

v   Model membantu komunikasi dengan para pengguna system

Slide 6: Alasan Pemodelan

v   Belajar dari proses pemodelan

v   Mereduksi kompleksitas dengan abstraksi

v   Mengingat semua hal detail

v   Berkomunikasi dengan anggota tim pengembang

v   Berkomunikasi dengan banyak pengguna dan stakeholder

v   Mendokumentasikan apa yang sudah dilakukan untuk pemeliharaan dan peningkatan di masa yang akan datang

Slide 7: Jenis Model

v   Jenis model yang berbeda digunakan dalam perkembangan sistem informasi

• Matematis—formula yang mendeskripsikan aspek teknik dari sistem
• Deskriptif—memo naratif, laporan, atau daftar yang mendeskripsikan aspek-aspek sistem
• Grafis—representasi diagram dan skematis dari suatu aspek system

Slide 8: Beberapa Model Deskriptif

Deskripsi naratif dari kebutuhan pemrosesan dinyatakan secara lisan oleh representasi RMO phone-order:

“Ketika langganan menelepon, saya bertanya dulu apakah mereka sudah memesan via telpun kepada kami sebelumnya, dan saya mencoba meminta mereka untuk memberitahukan nomor ID pelanggan yang mereka bisa temukan pada mailing label dalam catalog. Atau jika mereka menerka-nerka nomor pelanggannya, saya harus melihatnya berdasarkan nama dan melakukan proses eliminasi, melihat semua Smiths di Dayton, sebagai contoh, hingga saya menemukan nama yang benar. Kemudian, saya bertanya catalog apa yang mereka lihat, yang kadang-kadang out-of-date. Jika kasus ini terjadi, maka saya menjelaskan bahwa banyak produk masih ditawarkan, tapi harganya berbeda. Secara alami, mereka menunjuk suatu nomor halaman, yang mana tidak membantuku karena katalognya berbeda, tapi saya meminta mereka untuk memberitahuku tentang ID yang ada…

Daftar input untuk sistem pendukung pelanggan RMO

Item inquiry

New order

Order change request

Order status inquiry

Order fulfillment notice

Back-order notice

Order return notice

Catalog request

Customer account update notice

Promotion package detail

Customer charge adjustment

Catalog update details

Special promotion details

New catalog details

Slide 9: Gambaran Umum Model yang Digunakan dalam Analisis dan Desain

v   Aktivitas fase analisis disebut “define system requirements”

• Model logis
• Menyediakan detail tanpa memperhatikan teknologi yang spesifik

v   Fase desain

• Model fisik
• Menyediakan detil teknis
• Extend logical models
• Memperluas model logis

Slide 10: Model yang Dibuat dengan Aktivitas Analisis

Lihat slide aslinya

Slide 11: Model yang Digunakan dalam Desain

Lihat slide aslinya

Slide 12: Events, Activities, and Use Cases

v   Use Case

• Aktivitas yang dilakukan sistem dalam merespon permintaan pengguna
• “case” di mana sistem digunakan oleh actor

v   Teknik-teknik untuk mengidentifikasi use cases

• Mengidentifikasi tujuan pengguna

Ø      Tiap tujuan pada level elementary business process (EBP) merupakan sebuah use case

Ø      EBP—tugas yang dikerjakan oleh satu pengguna, dalam satu tempat untuk merespon event bisnis, yang menambah nilai bisnis yang terukur, dan meninggalkan sistem dan data dalam keadaan yang konsisten

• Teknik dekomposisi event
• Teknik analisis CRUD (membuat, membaca, memperbaharui, menghapus)

Slide 13: Mengidentifikasi Use Cases Berdasarkan Tujuan Pengguna

v   Pengguna/Actor

• Order clerk

Tujuan Pengguna

Ø     Melihat ketersediaan produk

Ø     Membuat order baru

Ø     Memperbaharui pesanan

• Shipping clerk

Tujuan Pengguna

Ø     Mencatat pemenuhan pesanan

Ø     Mencatan pesanan yang dikembalikan

• Merchandising manager

Tujuan Pengguna

Ø     Membuat promosi special

Ø     Membuat laporan aktivitas katalog

Slide 14: Dekomposisi Event

v   Event bisnis memacu elementary business processes (EBPs)

v   EBPs berada pada level yang tepat dari analisis untuk use cases

v   Mengidentifikasi event bisnis untuk mendekomposisi ke dalam activities/use cases

v   Dekompisi event, jadi, digunakan oleh

• Pendekatan tradisional untuk mengidentifikasi activities
• Pendekatan OO untuk mengidentifikasi use cases

Slide 15: Jenis-Jenis Events

v   Eksternal

• Sistem Luar
• Diinisiasi oleh agen eksternal atau actor

v   Temporal

• Terjadi sebagai hasil pencapaian suatu titik pada waktunya
• Berdasarkan batas waktu sistem

v   State

• Sesuatu di dalam sistem mendukung kebutuhan pemrosesan

Slide 16: Events Mempengarui Sistem Pemrosesan Charge Account Mengarah ke Use Cases

Lihat slide aslinya

Slide 17: Daftar Nama Event Eksternal

Event eksternal mencari hal berikut:

v   Agen eksternal menginginkan sesuatu yang dihasilkan dalam suatu transaksi

v   Agen eksternal menginginkan suatu informasi

v   Data diubah dan harus diupdate

v   Manajemen menginginkan suatu informasi

Slide 18: Daftar Nama Event Temporal

Event temporal mencari:

v   Output internal yang dibutuhkan

• Laporan manajemen (ringkasan atau eksepsi)
• Laporan operasional (transaksi rinci)
• Rekening dan dokumen internal (mencakup daftar gaji)

v   Output eksternal yang dibutuhkan

• Statement, laporan status, rekening, tanda mata

Slide 19: Mengidentifikasi Events

v   Bisa sulit menentukan

v   Sering bingun dengan kondisi dan respon

v   Mungkin berguna untuk mengikuti transaction’s life cycle

v   Events tertentu ditinggalkan menuju fase desain

• Kontrol sistem untuk memproteksi integritas sistem
• Asumsi teknologi yang sempurna menangguhkan events

Slide 20: Urutan Tindakan yang Mengarah ke hanya pada Satu Event yang Mempengaruhi Sistem

v   Pelanggan berpikir untuk mendapatkan kemeja baru

v   Pelanggan pergi ke mall menggunakan mobil

v   Pelanggan mencoba satu kemeja di Sears

v   Pelanggan pergi ke Wal-Mart

v   Pelanggan mencoba satu kemeja di Wal-Mart

v   Pelanggan membeli sebuah kemeja (event yang secara langsung mempengaruhi sistem)

Slide 21: Urutan “Transaksi” untuk Satu Pelanggan Khusus yang Dihasilkan dalam Banyak Event

v   Pelanggan meminta catalog

v   Pelanggan ingin mengecek keberadaan produk

v   Pelangga membuat pesanan

v   Pelanggan mengubah atau membatalkan pesanan

v   Pelanggan ingin mengecek status pesanan

v   Pelanggan ingin memperbaharui informasi account

v   Pelanggan mengembalikan produk

Slide 22: Event  Ditunda hingga Fase Desain

v   Pengguna ingin masuk ke sistem

v   Pengguna ingin mengubah password

v   Pengguna ingin mengubah setting preferensi

v   Crash sistem membutuhkan recovery basis data

v   Waktu untuk memback-up basis data

v   Waktu untuk meminta pengguna mengubah password

Jangan terlalu mengkhawatirkan ini hingga fase desain

Slide 23: Event dalam Kasus RMO

v   Events eksternal yang penting melibatkan para pelanggan

• Pelanggan mengecek keberadaan produk, pelanggan membuat pesanan, pelanggan mengubah atau membatalkan pesanan

v   Event eksternal lainnya melibatkan departemen- departemen

• Pengiriman untuk memenuhi pesanan, marketing mengirim promosi kepada pelanggan, merchandising memperbaharui katalog

v   Event temporal mencakup laporan periodik

• Waktu untuk membuat laporan ringkas pemesanan, waktu untuk membuat laporan ringkas pemenuhan pesanan

Slide 24: Informasi tentang Tiap Event pada Event Table: Katalog Informasi tentang Use Case Masing-Masing

Lihat slide aslinya

Slide 25: RMO Event Table

Lihat slide aslinya

Slide 26: “Thing” dalam Domain Masalah

v   Menentukan kebutuhan sistem dengan memahami informasi sistem yang harus disimpan

v   Menyimpan informasi tentang things dalam domain masalah yang orang-orang hubungkan ketika mereka melakukan pekerjaannya

v   Analis mengidentifikasi jenis-jenis things ini dengan mempertimbangkan tiap use case dalam event table

• Things apa yang sistem harus ketahui tentang dan informasi apa yang harus disimpan?

Slide 27: Jenis-jenis Things

Lihat slide aslinya

Slide 28: Prosedur untuk Mengembangkan Daftar Tings awal

v   Langkah 1: Menggunakan event table dan informasi tentang tiap use case, mengidentifkas semua nouns

v   Langkah 2: Menggunakan informasi lain dari sistem yang ada, prosedur terbaru, dan laporan atau formulir terbaru, menambah produk atau kategori informasi yang dibutuhkan

v   Langkah 3: Memperhalus daftar dan mencatat asumsi atau isu-isu untuk menjelajah

• Lihat Figure 5-18 sebagai contoh RMO

Slide 29: Karakteristik Things

v   Hubungan

o       Secara alami terjadi asosiasi antara things khusus

o       Terjadi dalam dua arah

o       Jumlah asosiasi adalah kardinalitas atau multiplicity

Ø      Binary, unary, ternary, n-ary

v   Atribut

• Satu penggalan informasi khusus tentang thing

Slide 30: Hubungan Alami Terjadi di antara Things

Lihat slidenya

Slide 31: Cardinality/Multiplicity Hubungan

v   Mr. Jones belum membuat pesanan, tapi ada kemungkinan membuatnya terlambat: Cardinality/Multiplicity adalah nol atau lebih—hubungan pilihan

v   Pesanan khusus dibuat oleh Mr. Smith. Tidak ada pesanan tanpa keterangan siapa pelanggannya: Cardinality/Multiplicity adalah satu dan hanya satu—hubungan mandatory

v   Isi pesanan pada produk yang paling sedikit, tapi bisa memuat beberapa produk: Cardinality/Multiplicity adalah satu atau lebih—hubungan mandatory

Slide 32: Atribut dan Value

Lihat slide aslinya

Slide 33: Entitas Data

v   Sistem thing harus menyimpan data tentang pendekatan IS tradisional

v   Dimodelkan dengan entity-relationship diagram (ERD)

v   Model kebutuhan digunakan untuk membuat model desain basis data untuk basis data relasional

Slide 34: Objek

v   Objek melakukan pekerjaan dalam sistem dan menyimpan informasi dalam pendekatan berorientasi objek

v   Objek memiliki behavior dan atribut

• Class – tipe thing
• Object – tiap thing khusus
• Methods – behaviors objek dari class

v   Objek memuat value untuk atribut dan metode untuk beroperasi dalam atribut-atribut itu

v   Objek di enkapsulasi—self-contained unit

Slide 35: Entitas Data Dibandingkan dengan Objek

Lihat slide aslinya

Slide 36: The Entity-Relationship Diagram (ERD)

Lihat slide aslinya

Slide 37: Cardinality Symbols of Relationships for ERD

Lihat slide aslinya

Slide 38: Expanded ERD with Attributes Shown

Lihat slide aslinya

Slide 39: Customers, Orders, and Order Items

Lihat slide aslinya

Slide 40: ERD with Many-to-Many Relationship

Lihat slide aslinya

Slide 41: Many-to-Many Relationship Converted to Associative Entity to Store Grade Attribute

Lihat slide aslinya

Slide 42: RMO Customer Support System ERD

Lihat slide aslinya

Slide 43: The Class Diagram

v   Unified Modeling Language (UML) diagram

v   Domain model class diagram

• Memodelkan things dalam domain kerja pengguna
• Digunakan untuk menentukan kebutuhan OO (sangat mirip dengan entitas dalam ERD)

v   Mendesain class diagram

• Memodelkan software classes
• Menambah metode sebagai behaviors
• Digunakan dalam design activity

Slide 44: UML Class Symbol

v   Customer => Nama class

v   Name          =>Atribut: Semua objek dalam class yang memiliki nilai untuk

Address                  masing-masing

phone

v   AddNew() => Metode: semua objek class yang menggetahui bagaimana

Delete()                  menjalankan operasi

Change()

ConnectToAcoount()

Slide 45: Simple Domain Model Class Diagram

Customer Order OrderItem

custNumber                             ordered                                               itemId

name                1 places 0..*    orderDate        1 consists of 1..*          quantity

billAddress                              amount                                                price

homePhone

officePhone

v   Tidak ada metode yang ditampikan dalam domain model

• Domain classes itu bukan software classes

v   Sangat mirip dengan ERD pada Figure 5-25

• UML and domain model dapat digunakan pada tempat ERD dalam pendekatan tradisional

Slide 46: Multiplicity of Associations

Lihat slide aslinya

Slide 47: University Course Enrollment Domain Model Class Diagram

Lihat slide aslinya

Slide 48: Refined Model with Association Class and Grade Attribute

Lihat slide aslinya

Slide 49: Konsep Class yang lebih Kompleks

v   Hirarki generalisasi/spesialisasi

• Superclasses umum ke sub kelas yang dikhususkan
• Inheritance membolehkan sub kelas untuk berbagi karakteristik super kelasnya

v   Whole-part hierarchies (object dan bagiannya)

• Agregasi—bagan-bagian yang bisa ada secara terpisah
• Komposisi—bagian-bagian yang tidak bisa ada secara terpisah

Ø      Tangan  memiliki jari dan ibu jari

Slide 50: A Generalization/Specialization Class Hierarchy for Motor Vehicles

Lihat slide aslinya

Slide 51: A Generalization/Specialization Class Hierarchy for RMO Orders

Lihat slide aslinya

Slide 52: Whole-Part Aggregation Relationships

Lihat slide aslinya

Slide 53: RMO Domain Model Class Diagram

Lihat slide aslinya

Slide 54: Design Class Diagram Notation: Software Classes with Methods

Lihat slide aslinya

Slide 55: Course Enrollment Design Class Diagram with Association Class

Lihat slide aslinya

Slide 56: Expanded Course Enrollment Design Class Diagram

Lihat slide aslinya

Slidee 57: Where You Are Headed

Lihat slide aslinya

Slide 58: Rangkuman

v   Fase analisis—menentukan kebutuhan sistem

v   Model dibuat untuk proses pembelajaran lebih lanjut, mereduksi kompleksitas, berkomunikasi dengan anggota tim, dan mendokumentasikan kebutuhan-kebutuhan

v   Banyak jenis model yang digunakan

• Matematis, deskriptif, grafis

v   Langkah kunci awal dalam pemodelan adalah mengidentifikasi dan membuat list

• Events yang membutuhkan use case dalam sistem
• Pengguna things berhubungan dengan lingkungan kerja

Slide 59: Rangkuman (lanjutan)

v   Use cases (activities) diidentifikasi dari tujuan-tujuan pengguna dan business event yang memicu proses bisns dasar

v   Businesss event itu mengesankan, dapat dideskripsikan, dan terjadi pada waktu dan tempat yang khusus

• External events, temporal events, and state events

v   Event table mencatat event, trigger, source, use case, respond an tujuan

• Katalog informasi tentang masing-masing use case

Slide 60: Ringkasan (lanjutan)

v    “Things” apapun yang pengguna hubungkan dan sistem ingat, seperti pelanggan membuat pesanan

v   Pendekatan tradisional menggunakan entity-relationship diagrams (ERD) untuk entitas data, atribut entitas data, dan relasi antar entitas

v   Pendekatan berorientasi objek menggunakan UML class diagrams untuk kelas, atribut, metode kelas, dan asosiasi antar kelas

v   Domain model class diagram (aktivitas kebutuhan)

v   Design class diagram (aktivitas desain)

***

Original Title: Systems Analysis and Design in a Changing World, Fourth Edition

Chapter 5 Modeling System Requirements

Source: Materi Mata Kuliah S2 Ilmu Komputer Institut Pertanian Bogor (IPB) 2010/2011

Bab 4 Memulai Analisis: Investigasi Kebutuhan Sistem

Diterjemahkan oleh: Komarudin Tasdik

http://komarudintasdik.wordpress.com

Slide 2: Tujuan Pembelajaran

v Mendeskripsikan aktivitas-aktivitas fase systems analysis life cycle

v Menjelaskan efek membangun kembali proses bisnis pada aktivitas-aktivitas fase analisis

v Mendeskripsikan perbedaan antara kebutuhan fungsional dan non-fungsional sistem

v Mengidentifikasi dan memahami jenis perbedaan para pengguna yang akan terlibat dalam investigasi kebutuhan sistem

Slide 3: Tujuan Pembelajaran (lanjutan)

v Mendeskripsikan jenis informasi yang dibutuhkan untuk mengembangkan kebutuhan sistem

v Menentukan kebutuhan sistem melalui review dokumentasi, interview, observasi, prototype, kuesioner, penelitian vendor, dan pembahasan desain aplikasi terkait

v Membahas kebutuhan validasi kebutuhan sistem untuk menjamin akurasi dan kelengkapan serta penggunaan walkthrough terstruktur

Slide 4: Gambaran Umum

v Fase analisis keterampilan SDLC yang dibutuhkan

• Penemuan fakta untuk investigasi kebutuhan sistem
• Analis harus mengkaji detail proses-proses bisnis dan operasi-operasi harian
• Analis harus banyak mengetahui seperti para user domain bisnis untuk membangun kredibilitas
• Analis membawa perspektif segar untuk suatu masalah
• Pemodelan proses-proses bisnis berdasarkan kebutuhan sistem

Slide 5: Fase Analisis yang Lebih Detail

v Mengumpulkan informasi

v Menetapkan kebutuhan sistem

• Fungsional dan non-fungsional

v Kebutuhan-kebutuhan prioritas

v Prototype untuk feasibilitas dan discoveri

v Menghasilkan dan mengevaluasi alternatif-alternatif

v Mereview rekomendasi dengan manajemen

Slide 6: Aktivitas-Aktivitas Fase Analisis

v Fase perencanaan proyek

v Aktivitas-Aktivitas fase analisis

• Mengumpulkan informasi
• Menetapkan kebutuhan sistem
• Kebutuhan prioritas
• Prototype untuk feasibilitas dan discoveri
• Menghasilkan dan mengevaluasi alternatif-alternatif
• Mereview rokemendasi dengan manajemen

v Fase Desain

v Fase Implementasi

v Fase Support

Slide 7: Aktivitas Fase Analisis dan Pertanyaan Kuncinya

v Aktivitas Fase Analisis

• Mengumpulkan informasi
• Menetapkan kebutuhan sistem
• Memprioritaskan kebutuhan
• Prototype untuk feasibiltas dan discoveri
• Menghasilkan dan mengevaluasi alternatif-alternatif
• Mereview rekomendasi dengan manajemen

v Pertanyaan kunci

• Apakah kita memiliki semua informasi (dan wawasan) yang kita butuhkan untuk menentukan apa yang harus sistem lakukan?
• Detail apa  yang kita butuhkan untuk membangun sistem itu?
• Apa hal yang paling penting harus sistem lakukan?
  • – Apakah kita sudah membuktikan bahwa teknologi yang diusulkan dapat melakukan apa yang harus kita lakukan dengan bantuan sistem tersebut?

– Apakah kita sudah membangun beberapa prototype untuk menjamin para user benar-benar memahami potensi yang bisa dilakukan sistem baru?

• Apa cara terbaik untuk membangun sistem
• Apakah kita harus melanjutkan desain dan mengimplementasikan sistem yang kita usulkan?

Slide 8: Reengineering Proses Bisnis dan Analiss

v Pendekatan strategis fundamental untuk mengorganisir perusahaan

v Mempersingkat proses-proses bisnis seefisien dan seefektif mungkin

v Asumsi-asumsi dasar pertanyaan untuk melakukan bisnis dan mencari cara yang lebih baik

v Menggunakan IT sebagai BPR enabler

v Analis sistem mungkin menemukan peluang untuk perbaikan proses

v Proyek apapun mungkin mencakup komponen-komponen BPR

Slide 9: Zachman Framework untuk Enterprise Architecture

Lihat slide aslinya

Slide 10: Kebutuhan Sistem

v Kemampuan dan keterbatasan sistem baru

v Kebutuhan fungsional

• Aktivitas-aktivitas sistem harus berjalan (use cases)
• Berdasarkan prosedur dan fungsi bisnis
• Didokumentasikan dalam model analisis

v Kebutuhan non-fungsional

• Lingkungan teknis atau target performance
• Kebutuhan usability, reliability, dan security

Slide 11: Stakeholders—Sumber Kebutuhan Sistem

v  Orang-orang yang berkepentingan dengan implementasi sistem yang sukses

v  Tiga kelompok utama stakeholders

• Users (menggunakan sistem)
• Clients (membayar dan memiliki sistem)
• Technical staff (menjamin operasi sistem)

v Setiap jenis stakeholder diidentifikasi oleh analis

Slide 12: Stakeholders yang tertarik dalam Perkembangan Sistem Baru

Lihat slide aslinya

Slide 13: User sebagai Stakeholders

v Peran user horizontal—informasi melintasi departemen-departemen

v Vertical user roles – information needs of clerical staff, middle management, and senior executives

v Peran user vertical—kebutuhan informasi clerical staff, middle management, dan senior executives

• Para pengguna bisnis melakukan operasi-operasi harian
• Para pengguna informasi membutuhkan informasi terbaru
• Para pengguna manajemen membutuhkan informasi ringkas
• Para pengguna eksekutif membutuhkan informasi strategis
• Para pengguna eksternal mungkin memiliki akses ke system

Slide 14: Teknik Pengumpulan Informasi

v Fase analisis dilakukan untuk memahami fungsi bisnis dan mengembangkan kebutuhan sistem

v Pendekatan terstruktur asli

• Membuat model sistem yang ada
• Memperoleh kebutuhan dari model sistem yang ada

v Pendekatan terbaru

• Mengidentifikasi kebutuhan logis untuk sistem baru
• Menyeimbangkan review fungsi bisnis terbaru dengan kebutuhan sistem baru

Slide 15: Hubungan antara Pengumpulan Informasi dan Pembangunan Model

Lihat slide aslinya

Slide 16: Tema untuk Pertanyaan Pengumpulan Informasi

v Tema

• Apakah yang dimaksud dengan operasi dan proses bisnis?
• Bagaimana seharusnya operasi-operasi itu dilakukan?
• Informasi apa yang dibutuhkan untuk menjalankan operasi itu?

v Pertanyaan untuk Pengguna

• Apa yang anda kerjakan?
• Bagaimana anda mengerjakannya? Langkah apa yang anda ikuti?
• Informasi apa yang anda gunakan? Formulir atau laporan apa yang anda gunakan?

Slide 17: Metode Penemuan Fakta

v Mereview laporan, formulir, and deskripsi prosedur yang ada

v Menginterview dan mendiskusikan proses-proses dengan para pengguna

v Mengobservasi dan mendokumentasikan proses-proses bisnis

v Membangun prototypes

v Mendistribusian dan mengumpulkan kuesioner

v Mengadakan pembahasan joint application design (JAD)

v Meneliti solusi-solusi vendor

Slide 18: Mereview Laporan, Formulir, dan Deskripsi Prosedur yang Ada

v Sumber: Organisasi profesional industri eksternal yang besar dan publikasi perdagangan

v Sumber: Dokumen bisnis dan deskripsi prosedur yang ada di dalam organisasi

• Mengidentifikasi peran, ketidaksesuaian, dan redundansi bisnis
• Berhati-harilah terhadap bahan kuno
• Mendapatkan pemahaman utama tentang proses
• Menggunakan petunjuk/isyarat visual untuk memandu interview

Slide 19: Sample Order Form for RMO

Lihat aslinya

Slide 20: Memimpin Interview dan Diskusi dengan Pengguna

v Cara efektif untuk memahami fungsi dan peran bisnis

v Konsumsi waktu dan kemahalan sumber daya

v Mungkin membutuhkan berbagai pembahasan untuk

• Menemui semua pengguna
• Memahami semua kebutuhan pemrosesan

v Dapat bertemu dengan individual atau kelompok pengguna

v Daftar pertanyaan-pertanyaan detail yang dipersiapkan

Slide 21: Daftar Nama Contoh untuk Mempersiapkan Interview User

Daftar Nama untuk Memandu Interview

v Sebelum

• Menetapkan tujuan untuk interview
• Menentukan pengguna yang tepat yang akan dilibatkan
• Menentukan anggota tim proyek untuk berpartisipasi
• Membuat daftar pertanyaan dan isu untuk didiskusikan
• Mereview dokumen dan materi yang berhubungan
• Menset waktu dan lokasi
• Memberitahu semua partisipan tentang tujuan, waktu, dan lokasi

v Selama

• Mengenakan baju sewajarnya
• Datang tepat waktu
• Mencari kondisi pengecualian dan error
• Penyelidikan detail
• Mengambil catatan dengan teliti
• Mengidentifikasi dan mendokumentasikan item-item yang belum terjawab atau membukan pertanyaan-pertanyaan

v Setelah

• Mereview catatan untuk akurasi, kelengkapan, dan pemahaman
• Mentransfer informasi kepada model dan dokumen yang tepat
• Mengidentifikasi area-area yang membutuhkan klarifikasi lebih lanjut
• Mengucapkan catatan terima kasih jika tepat

Slide 22: A Sample Open-Items List

Lihat slide aslinya

Slide 23: Mengobservasi dan Mendokumentasikan Proses-Proses Bisnis

v Mengubah dari walkthroughs kantor ke pengerjaan tugas-tugas aktual

v Tidak perlu mengobservasi semua proses-proses pada level detail yang sama

v Mungkin membuat para pengguna takut, sehingga menggunakan pengertian yang biasa

v Dapat mendokumentasikan workflows dengan UML activity diagrams

Slide 24: Activity Diagram Symbols

Lihat slide aslinya

Slide 25: Activity Diagram that Models a Workflow

Lihat slide aslinya

Slide 26: Membangun Prototype

v Model pengerjaan awal dari komponen sistem yang lebih besar dan lebih kompleks

• Discovery, design, melibatkan prototypes

v Prototype harus

• Operatif
  • Pengerjaan model untuk menyediakan “look and feel”
• Fokus menyelesaikan sasaran tunggal
• Cepat
  • Dibangun dan dimodifikasi secara cepat dengan CASE tools

Slide 27: Mendistribusikan dan Mengumpulkan Kuesioner

v Informasi yang terbatas dan spesifik dari sejumlah besar stakeholders

v Wawasan awal tentang bisnis

v Tidak begitu sesuai untuk pengumpulan informasi detail

v Closed-ended questions mengarahkan orang menjawab pertanyaan

v Open-ended questions mendukung diskusi dan elaborasi

Slide 28: Memimpin Pembahasan Joint Application Design

v Mempercepat investigasi kebutuhan sistem

v Mencoba meringkas penemuan fakta, pemodelan, formasi kebijakan, dan aktivitas verifikasi ke dalam frame waktu yang lebih singkat

v Faktor kritis untuk memiliki semua kata-kata stakeholder penting

Slide 29: Joint Application Design Participants

v Session leader dilatih dalam dinamika grup dan fasilitasi grup JAD

v Mengetahui banyak tentang bisnis dan pengguna sistem serta pembuat kebijakan

v Representasi staf teknis untuk menangani

• Konfigurasi komputer dan jaringan
• Lingkungan operasi
• Isu-isu keamanan

v Project team members

v Anggota tim proyek

Slide 30: Fasilitas Joint Application Design

v Diaraahkan dalam ruang khusus

• Membatasi interupsi
• Boleh off-site

v Sumber daya

• Overhead projector, white board, flip charts, work material
• Electronic support (laptops)
• CASE tools
• Group support systems (GSS)

Slide 31: Facilitas JAD

Lihat slide aslinya

Slide 32: Penelitian Solusi Vendor

v Banyak masalah telah diatasi oleh perusahaan-perusahaan lain

v Kontribus positif solusi vendor

• Sering menyediakan ide-ide baru
• Bisa menjadi state of the art
• Lebih murah dan kurang berisiko

v Bahaya

• Bisa memperoleh solusi sebelum memahami masalah

Slide 33: Teknik Bermanfaat dalam Penelitian Vendor

v Spesifikasi teknis dari vendor

v Sistem demo or percobaan

v Referensi clients yang ada

v Kunjungan on-site

v Printout dari screens dan laporan

Slide 34: Validasi Kebutuhan

v Memastikan informasi yang dikumpulkan itu tepat

v Walkthrough terstrukur

• Pengertian yang efektif dari implementasi kontrol kualitas awal dalam proyek
• Verify and validate system requirements
• Memverifikasi dan memvalidasi kebutuhan sistem
• Mereview penemuan dari investigasi dan model berdasarkan penemuan

v Project manager responsible for system quality

v Manajer proyek bertanggung jawab terhadap kualitas sistem

• Analis sistem, manajer proyek adalah partners

Slide 35: Ringkasan

v Aktivitas fase analisis

• Mengumpulkan informasi
• Menentukan kebutuhan sistem
• Memprioritaskan kebutuhan
• Prototype untuk feasibility dan discovery
• Menghasilkan dan mengevalusai alternatif-alternatif
• Mereview rekomendasi-rekomendasi dengan manajemen

v BPR and Zachman Framework bisa membantu dengan aktivitas fase analisis

Slide 36: Ringkasan (lanjutan)

v Mengumpulkan kebutuhan sistem

• Fungsional dan non-fungsional
• Bekerja dengan stakeholder yang berbeda-beda (users, clients, staf teknis)

v Jenis informasi apa yang saya butuhkan?

• Apa yang dimaksud dengan proses dan operasi bisnis?
• How are the business processes performed?
• Bagaimana proses bisnis dilakukan?
• Apa yang dimaksud dengan kebutuhan informasi?

Slide  37: Ringkasan (lanjutan)

v Teknik pengumpulan informasi primer

• Mereview laporan, formulir, dan deskripsi prosedur yang ada
• Memimpin interview dan diskusi dengan para pengguna
• Mengobervasi dan mendokumentasikan proses-proses bisnis
• Membangun model pengerjaan prototype
• Mendistribusian dan mengumpulkan kuesioner
• Mengadakan pembahasan JAD
• Meneliti solusi-solusi vendor

Original Title: Systems Analysis and Design in a Changing World, Fourth Edition

Chapter 4 Beginning the Analysis: Investigating System Requirements

Source: Materi Mata Kuliah S2 Ilmu Komputer Institut Pertanian Bogor (IPB) 2010/2011

Judul Buku: Systems Analysis and Design in a Changing World, Edisi 4

Bab 16 Trend Baru dalam Pengembangan Sistem

(Slide 1 s.d 3 berisi tujuan pembelajaran)

GAMBARAN UMUM

• Disiplin IS selalu dinamis dan berubah
• Kebutuhan sistem yang lebih kompleks mengharuskan semua tools baru

–          The Unified Process (UP)

–          Radikal, pendekatan adaptif, mencakup Agile Development, Extreme Programming, dan Scrum

–          Arsitektur Model-Driven untuk sistem level perusahaan

–          Kerangka dan komponen objek meningkatkan produktivitas dan kualitas

Prinsip-Prinsip Software dan Latihan

• Di mana pun, komputerisasi merupakan trend baru di masyarakat kita

–          Menggunakan teknologi komputer dalam setiap aspek hidup kita

• Usaha mengembangkan solusi baru banyak banyak persyaratannya
• Trend-trend baru dalam modeling dan proses pengembangan menggunakan lima prinsip-prinsip penting
• Abstraksi

–          Proses mengekstrak prinsip-prinsip utama dari sejumlah fakta atau statement

–          Contoh: metamodels menggambarkan karakteristik model lain

• Model dan Modeling

–          Abstraksi sesuatu dalam dunia nyata, merepresentasikan sejumlah properties tertentu

• Patterns

–          Solusi standar untuk suatu masalah atau template yang dapat digunakan untuk mengatasi masalah

• Reuse

–          Membangun solusi dan komponen standar yang bisa digunakan berkali-kali

• Metodologi

–          Proses—mencakup aturan, panduan, dan teknik—yang menentukan bagaimana sistem dibangun

Pendekatan Adaptif untuk Pengembangan

• Berbeda dengan spektrum akhir dari pendekatan prediktif (lihat Bab 2)
• Memungkinkan ketidaktentuan
• Menggunakan kontrol empiris, bukan kontrol prediktif

–          Menggambarkan proses-proses, yakni yang bersifat variabel dan tidak terprediksi

–          Memonitor kemajuan dan membuat koreksi sambil jalan

Pendekatan Adaptif untuk Pengembangan—Karakteristik

• Kurang perhatian pada analisis, desain, dan dokumentasi di muka sekali
• Lebih fokus pada pengembangan inkremental
• Lebih banyak keterlibatan user dalam tim proyek
• Mengurangi perencanaan detail

–          Digunakan hanya untuk fase-fase near-term work

• Schedule kontrol yang padat dengan menyesuaikan pekerjaan ke dalam boks waktu diskrit
• Lebih banyak menggunakan tim-tim kerja kecil yang mengorganisir sendiri

The Unified Process (UP)

• Metodologi pengembangan sistem berorientasi objek (proses pengembangan sistem)
• Ditawarkan oleh Rational/IBM, UP dikembangkan oleh Booch, Rumbaugh, dan Jacobson
• UP harus disesuaikan dengan kebutuhan-kebutuhan organisasi dan proyek
• Siklus hidup iteratif tinggi
• Proyek akan menjadi use-case driven and modeled using UML

Siklus Hidup Proses Terintegrasi

• UP life cycle

–          Mencakup empat fase yang terdiri atas iterasi-iterasi

–          Iterasi adalah “mini-projects”

• Insepsi: mengembangkan dan menyempurnakan visi sistem
• Elaborasi: menentukan kebutuhan dan desain serta mengimplementasikan arstektur utama
• Konstruksi: melanjutkan desain da n implementasi rutin, bagian-bagian yang tidak terlalu berisiko
• Transisi: memindahkan sistem ke dalam mode operasional

Siklus hidup Pemrosesan Teintegrasi: slide 12

Fase dan Tujuan UP

Disiplin UP

• UP menentukan disiplin-disiplin yang digunakan pada setiap fase
• Disiplin—sejumlah aktivitas pengembangan yang terhubung secara fungsional
• Tiap iterasi mencakup aktivitas-aktivitas dari semua disiplin
• Aktivitas-aktivitas pada tiap disiplin menghasilkan artifacts—models, dokumen, source code, dan executables
• Mengkaji CIS/MIS berarti mengkaji berbagai teknik dari disiplin-disiplin ini
• Enam disiplin utama dari pengembangan UP

–          Pemodelan, kebutuhan, desain, implementasi, testing, dan deployment bisnis

• Tiga disiplin support tambahan

–          Manajemen, konfigurasi, dan manajemen perubahan, serta lingkungan proyek

Disiplin UP yang digunakan dalam jumlah yang berbeda di tiap iterasi: slide 16

Model siklus hidp UP: slide 17

FILOSOFI DAN PEMODELAN PENGEMBANGAN CERDAS

Agile Development

• Sebuah filosofi dan sejumlah panduan untuk mengembangkan software dalam lingkungan yang tidak diketahui dan berubah cepat

–          Membutuhkan kecerdasan—mampu mengubah arah dengan cepat, bahkan di tengah-tengah proyek

• Agile Modeling

–          Sebuah filosofi tentang bagaimana membangun berbagai model, sebagian bersifat formal dan detail, serta yang lainnya sederhana dan minimalis

Filosofi dan nilai-nilai pengembangan cerdas

• Merespon perubahan yang terjadi pada perencanaan

–          Proyek cerdas adalah chaordic—chaotic and ordered (semrawut dan rapi)

• Individual dan interaksi di atas proses dan tools
• Menjalankan software di atas dokumentasi komprehensif
• Kolaborasi pelanggan di atas negosiasi kontrak

Metodologi Adaptif menggunakan Agile Modeling: slide 20

Prinsip-prinsip Agile Modeling

AM mengerjakan jenis pemodelan yang benar pada level detail yang benar untuk tujuan-tujuan yang benar

• Menggunakan model-model sebagai akhir pembangunan dan penyelesaian nya
• Tidak mendikte yang mana model yang akan dibangun atau seberapa formal membangun model-model tersebut
• Memiliki prinsip-prinsip dasar untuk mengekspresikan bahwa para developer harus memiliki sikap seperti mereka yang mengembangkan software

Prinsip-prinsip Agile Modeling

• Mengembangkan software sebagai tujuan utama anda
• Memungkinkan usaha selanjutnya sebagai tujuan kedua anda
• Meminimalisir aktivitas pemodelan anda—sedikit dan sederhana
• Mencakup perubahan, dan berubah secara inkremental
• Model dengan sebuah tujuan
• Membangun berbagai model
• Membangun model-model berkualitas tinggi dan mendapatkan feedback secara cepat
• Fokus pada konten daripada representasi
• Belajar dengan komunikasi terbuka
• Mengetahui model-model anda dan bagaimana menggunakannya
• Beradaptasi terhadap kebutuhan-kebutuhan proyek yang spesifik

Latihan Agile Modeling

• Iterative and incremental modeling

–          Menggunakan model-model yang benar

–          Menciptakan beberapa model paralel

–          Iterasi yang sering

–          Model dalam inkreman kecil

• Teamwork

–          Model dengan yang lainnya

–          Melibatkan user dan stakeholder lain

–          Berbagai kepemilikan model

–          Mempublikasikan model

• Simplicity

–          Menciptakan konten sederhana

–          Menggambarkan model secara sederhana

–          Menggunakan tools sederhana

• Validation

Membuktikannya dengan code

• Documentation

–          Membuang model temporer

–          Merumuskan model-model kontrak

–          Hanya mengupdate ketika model rusak

• Motivation

–          Model untuk berkomunikasi

–          Medel untuk memahami

Extreme Programming (XP)

• Adaptif, metodologi pengembangan cerdas diciptakan pada pertengahan tahun 1990
• Membuktikan praktek terbaik industri dan fokus padanya secara intens
• Mengkombinasikan praktek-praktek terbaik itu (dalam bentuk intensnya) dalam cara baru untuk memproduksi hasil yang lebih besar dari jumlah bagian-bagiannya

Nilai-nilai Inti XP

• Komunikasi

Terbuka, sering diskusi verbal

• Simplicity

Dalam mendesain dan mengimplementasikan solusi-solusi

• Feedback

Pada fungsionalitas, syarat/kebutuhan, desain, dan code

• Courage

Dalam menghadapi pilihan seperti membuang bad code atau bertahan terhadap schedule yang sangat padat

Praktek-Praktek XP

• Planning

Para user mengembangkan sejumlah cerita untuk menggambarkan apa yang harus sistem lakukan

• Testing

Tes ditulis sebelum solusi-solusi diimplementasikan

• Pair Programming

Dua programmer bekerja sama dalam mendesain, coding, dan testing

• Simple Designs

“KISS” dan desain berkelanjutan

• Refactoring

Memperbaiki code tanpa mengubah yang ada

• Memiliki code secara kolektif

Sebagian orang dapat memodifikasi beberapa bagian code

• Continuous integration

Bagian-bagian kecil dari code yang diintegrasikan ke dalam sistem secara harian atau lebih sering daripada itu

• System metaphor

Membimbing para anggota menuju visi sistem

• On-Site Customer

Interaksi user/pelanggan yang intensif itu dibutuhkan

• Small releases

Memproduksi release yang kecil dan sering untuk user/pelanggan

• Forty-hour work week

Proyek harus dimanage untuk menghindari kegagalan

• Coding standards

Mengikuti coding standards untuk meyakinkan fleksibilitas

Nilai-nilai inti XP dan Latihan

Aktivitas Proyek XP

• System-level activities

–          Terjadi sekali selama masing-masing proyek pengembangan

–          Melibatkan penciptaan cerita-cerita user untuk merencanakan release

• Release-level activities

–          Siklus dengan banyak waktu—sekali untuk tiap release

–          Dikembangkan dan diuji dalam satu periode tidak lebih dari beberapa minggu atau bulan

• Iteration-level activities

Melakukan pengkodean dan menguji subset fungsional spesifik dalam beberapa hari atau minggu

Pendekatan pengembangan XP: slide 31

SCRUM

• Metodologi pengembangan yang cepat, adaptif, dan self-organizing

Dinamai setelah rugby’s system untuk mendapatkan out-of-play ball into play

• Merespon situasi baru secepat dan sepositif mungkin
• Pendekatan kontrol empiris yang sebenarnya terhadap pengembangan software

Filosofi Srum

• Responsif terhadap perubahan cepat, lingkungan dinamis
• Sangat fokus pada level tim

Tim menggunakan kontrol total di atas organisasi dan proses pekerjaannya

• Menggunakan backlog produk sebagai mekanisme kontrol dasar

Memprioritaskan daftar kebutuhan user harus dipilih dan dikerjakan  selama proyek scrum

Organisasi Scrum

• Product owner

–          Client stakeholder untuk yang membangun sistem

–          Memelihara daftar backlog produk

• Scrum master

Orang dalam memimpin proyek scrum

• Scrum team or teams

–          Kelompok kecil dari para pengembang

–          Menyusun tujuan-tujuannya dan mendistribusikan perkejaan di antara mereka

Praktek Scrum

• Sprint

–          Proses pekerjaan dasar dalam scrum

–          A time-controlled mini-project

–          Firm 30-day time box dengan tujuan spesifik atau deliverable

• Bagian-bagian dari Sprint

–          Mulai dengan sesi perencanaan satu hari

–          Pertemuan scrum harian yang singkat untuk kemajuan laporan

–          Berakhir dengan review setengah hari terakhir

Proses pengembangan software scrum: lihat slide 36

MANAJEMEN PROYEK DAN METODOLOGI ADAPTIF

• Manajemen waktu proyek

–          Skup lebih kecil dan fokus pada tiap iterasi

–          Schedule pekerjaan realistis

• Manajemen skup proyek

–          Users dan clients bertanggung jawab terhadap skup itu

–          Scope control terdiri atas pengawasan sejumlah iterasi

• Manajemen pembiayaan proyek

–          Lebih sulit diprediksi karena tidak diketahui

• Manajemen komunikasi proyek

Kritis karena komunikasi verbal terbuka dab pekerjaan kolaboratif

• Manajemen kualitas proyek

Testing and refactoring berkelanjutan harus dijadwalkan

• Manajemen risiko proyek

Aspek-aspek risiko tinggi dialamatkan pada iterasi-iterasi awal

• Manajemen sumber daya manusia proyek

Tim mengorganisirnya sendiri

• Manajemen procurement proyek

–          Mengintegrasikan elemen-elemen yang diperoleh ke dalam proyek menyeluruh

–          Memverifikasi kualitas komponen-komponen

–          Meyakinkan komitmen kontraktual

Model-Driven Architecture—menggeneralisir solusi-solusi

• Model-Driven Architecture (MDA) adalah inisiatif OMG (Object Management Group)

–          Dibangun pada prinsip-prinsip abstraksi, pemodelan, penggunaan kembali, dan patterns

–          Menyediakan perusahaan kerangka untuk mengidentifikasi dan mengklasifkasikan semua pekerjaan pengembangan sistem yang dikerjakan dalam sebuah perusahaan

• MDA mengekstrak  features dan informasi sistem baru dan mengkombinasikannya ke dalam platform independent model (PIM)
• Platform-independent model (PIM)

–          Menggambarkan karakteristik sistem yang tidak spesifik untuk beberapa diagram deployment

–          Menggunakan UML

• Platform-specific model (PSM)

–          Menggambarkan karakteristik sistem yang mencakup kebutuhan deployment platform

• Sejumlah transformasi standar dengan OMG mengubah PSM menjadi PIM

Pengembangan Sistem dan MDA: lihat slide 42

Metamodels and Transitions di antara PIM, PSM, dan Code: slide 43

Partial Metamodel of UML Class Diagram: slide 44

Kerangka Objek

• Sejumlah kelas yang didesain untuk dipergunakan kembali dalam varian program
• Kelas-kelas di dalam kerangka objek yang disebut kelas-kelas fundamen

–          Dapat diorganisir ke dalam satu atau lebih hirarki warisan

–          Kelas-kelas khusus aplikasi dapat diambil dari kelas-kelas fundamen yang ada

Jenis Kerangka Objek

• User-interface classes

Biasanya digunakan objek-objek dalam GUI

• Generic data structure classes

Linked lists, binary trees, dan lain-lain, dan operasi pemrosesan terkait

• Relational database interface classes

Kelas-kelas untuk menciptakan dan melakukan operasi pada tabel-tabel

• Classes specific to an application area

Untuk penggunaan industri dan jenis aplikasi khusus

Dampak pada desain dan implementasi

• Frameworks harus dipilih di awal sebuah proyek
• Desain sistem harus sesuai dengan asumsi-asumsi spesifik tentang struktur dan operasi program aplikasi yang frame hadapi
• Personil desain dan pengembangan harus dilatih untuk menggunakan Frameworks secara efektif
• Berbagai Frameworks mungkin dibutuhkan, memerlukan kompatibilitas dan pengujian integrasi dahulu

Komponen-Komponen

• Modul-modul software yang disusun secara lengkap dan siap guna

Reusable packages of executable code

• Memiliki interface yang baik untuk mengkoneksikannya ke clients atau komponen-komponen lian

Public interfaces and encapsulated implementation

• Standardized and interchangeable

Mengupdate komponen-komponen tunggal yang tidak membutuhkan relinking, recompiling, and redistributing aplikasi keseluruhan

Standar Komponen dan Infrastruktur

• Interoperabilitas komponen-komponen yang membutuhkan standar untuk dikembangkan sehingga siap guna
• Komponen-komponen mungkin juga membutuhkan infrastruktur support standar

Komponen-komponen software lebih fleksibel ketika bergantung  pada pelayanan infrastruktur standar untuk menemukan komponen-komponen lain

• Standar jaringan dibutuhkan untuk komponen-komponen di lokasi yang berbeda

CORBA and COM+

• CORBA (Common Object Request Broker Architecture) adalah standar untuk koneksi dan interkasi komponen software yang dikembangkan oleh OMG

–          Object request broker (ORB) menyediakan direktori komponen dan pelayanan-pelayanan komunikasi

–          Internet Inter-ORB Protocol (IIOP) digunakan untuk berkomunikasi antar objek  dan ORBs

• Component Object Model Plus (COM+) adalah standar untuk koneksi dan interkasi komponen software yang dikembangkan oleh Microsoft

Enterprise JavaBeans

• Bagian dari framework objek ekstensif bahasa pemrograman Java (JDK)
• JavaBean dapat berjalan pada sebuah server dan berkomunikasi  dengan clients dab komponen lain menggunakan CORBA

–          JavaBean mengimplementasikan metode komponen yang dibutuhkan dan menindaklanjuti konvensi penamaan yang dibutuhkan  dari standar JavaBean

• Platform independent

Komponen-komponen dan siklus hidup pengembangan

• Pengadaan dan penggunaan kembali komponen merupakan pendekatan viable untuk penyelesaian kecepatan sistem

–          Komponen yang diadakan dapat membentuk semua atau sebagian sistem baru yang dikembangkan atau diimplementasikan kembali

–          Komponen dapat didesain in-house dan disebar dalam sistem baru yang dikembangkan dan diimplementasikan kembali

Menggunakan komponen-komponen yang tersedia—implikasi

• Software standar dan support dari komponen yang tersedia harus menjadi bagian dari penentuan kebutuhan teknis
• Kebutuhan support teknis  komponen membatasi pertimbangan pilihan selam desain arsitektur software

Monitoring System Performance

• Menguji desain berbasis komponen untuk mengestimasi pattern dan demand traffic jaringan pada hardware komputer
• Menguji kapasitas server yang ada dan infrastruktur jaringan untuk menentukan kemampuannya mengakomodasi komunikasi antar komponen
• Mengupgrade kapasista jaringan dan server terlebih dahulu sebelum pengembangan dan testing
• pengujian system performance selama pengembangan dan membuat penyesuaian yang dibutuhkan
• Monitoring System Performance berkelanjuran setelah deployment untuk mendeteksi permasalahan merging
• Redeploy components, upgrade kapasitas server, dan mengupgrade kapasitas jaringan untuk merefleksikan kondisi-kondisi perubahan

Pelayanan

• Metode baru dari penggunaan kembali software mungkin dilakukan dengan Internet—pelayanan eksternal yang diidentifikasi dan digunakan untuk aplikasi-aplikasi
• Disebut layanan web dan arsitektur berorientasi pelayanan
• Microsoft .NET merupakan standar berbasis SOAP
• Java 2 Web Services (J2WS) merupakan standar layanan dalam Java

Komunikasi komponen menggunakan SOAP: slide 57

RANGKUMAN

Metodologi pengembangan adaptif

• Unified Process (UP)
• Agile Modeling and Agile Development

Fleksibilitas dalam dunia bisnis yang tidak terprediksi

• Extreme Programming (XP)

Test ditulis dahulu; programmer bekerja secara pair

• Scrum

Menentukan tujuan spesifik yang dapat diselesaikan dalam empat minggu

• Model-Driven Architecture (MDA)

Menyediakan teknik-teknik untuk organisasi besar guna mengintegrasikan semua software dan semua pengembangan software melintasi seluruh perusahaan

• Penggunaan kembali user merupakan pendekatan fundamental untuk pengembangan cepat

–          Kerangka objek menyediakan tujuan dari penggunaan kembali software yang ada melalui warisan

–          Komponen merupakan unit-unit executable code yang dapat digunakan kembali dan berperans sebagai objek-objek terdistribusi

TERJEMAHAN INI BELUM DIEDIT

Sumedang, 4 September 2010

Judul Buku: Systems Analysis and Design in a Changing World, Edisi 4

Diterjemahkan oleh: Komarudin Tasdik

Bab 3 Analis sebagai Manager Proyek

(Slide 2 & 3 Tujuan pembelajaran)

Gambaran Umum

v Prinsip-Prinsip Dasar Manajemen Proyek

• Faktor-faktor sukes proyek
• Peran manager proyek
• Ruang lingkup ilmu manajemen proyek

v Bagaimana sistem informasi dimulai

• Bagian perencanaan strategis menyeluruh
• Respon terhadap kebutuhan bisnis yang mendesak

v Fase perencanaan proyek SDLC

v Contoh-contoh perencanaan proyek untuk RMO

Faktor Sukses Proyek

v Peran penting manajemen proyek untuk kesuksesan proyek pengembangan sistem

v 2000 Standish Group Study

• Hanya 28% proyek pengembangan sistem yang sukses
• 72% proyek dibatalkan, selesai dengan terlambat, selesai melebihi budget, dan/atau fungsinya terbatas

v Jadi, proyek membutuhkan planning, control, dan execution yang cermat

Alasan Kegagalan Proyek

v Kebutuhan yang tidak lengkap dan berubah

v Keterlibatan user terbatas

v Kelemahan dukungan eksekutif

v Kelemahan dukungan teknis

v Perencanaan proyek tidak baik

v Tujuan tidak jelas

v Kekurangan sumber daya yang dibutuhkan

Alasan Kesuksesan Proyek

v Penentuan kebutuhan sistem yang jelas

v Keterlibatan user substansial

v Dukungan manajemen atas (upper management)

v Perencanaan proyek yang cermat dan rinci

v Schedules dan milestones kerja realistis

Peran Manager Proyek

v Management proyek—mengorganisir dan mengarahkan orang untuk mencapai hasil yang telah direncanakan sesuai budget dan schedule yang telah direncanakan pula

v Kesuksesan atau kegagalan proyek tergantung pada skill manager proyek

• Permulaan proyek—merencanakan dan mengorganisir
• Selama proyek—memonitor dan mengontrol

v Responsibilitas internal dan eksternal

Responsibilitas Internal

v Mengidentifikasi tugas-tugas proyek dan membangun struktur work breakdown (laporan kerja)

v Mengembangkan schedule proyek

v Merekrut dan melatih anggota tim

v Memberikan tugas kepada kepada anggota tim

v Mengkoordinir aktivitas-aktivitas anggota tim dan subteam

v Mengamati risiko proyek

v Memonitor dan mengontrol project deliverables and milestones

v Memverifikasi kualitas project deliverables

Responsibilitas Eksternal

v Melaporkan status dan kemajuan proyek

v Membangun hubungan kerja yang baik dengan yang mengidentifikasi syarat sistem yang diperlukan

• Orang yang akan menggunakan sistem

v Bekerja langsung dengan client (sponsor proyek) dan stakeholders lain

v Mengidentifikasi kebutuhan-kebutuhan sumber daya dan memperoleh sumber daya

Various Titles/Roles of Project Managers

Participants in a System Development Project: lihat slide 12

Pekerjaan Manajemen Proyek

v Permulaan proyek

• Perencanaan proyek yang menyeluruh

v Selama proyek

• Manajemen eksekusi proyek
• Manajemen kontrol proyek
• Penutupan proyek

v Pendekatan manajemen proyek berbeda untuk

• SDLC prediktif
• SDLC adaptif

Project Management and SDLC Tasks for a Predictive Project: hal. 14

Project Management and SDLC Tasks for an Adaptive Project: hal. 15

Project Management Body of Knowledge (PMBOK)—Ruang Lingkup Manajemen Proyek Ilmu Pengetahuan

v Scope management

• Mengontrol fungsi-fungsi yang tercakup dalam sistem
• Mengontrol skup pekerjaan yang dilakukan oleh tim

v Time management

• Membangun schedule rinci dari semua pekerjaan proyek
• Memonitor kemajuan proyek terhadap milestones

v Cost management

• Memperhitungkan analisis biaya/keuntungan
• Memonitor berbagai biaya

v Manajemen Kualitas

• Membuat perencanaan kualitas dan mengontrol aktivitas-aktivitas untuk tiap fase proyek

v Manajemen Sumber Daya Manusia

• Merekrut dan menyewa anggota tim proyek
• Melatih, memotivasi, membangun tim

v Manajemen Komunikasi

• Mengidentifikasi stakeholders dan komunikasinya
• Membangun komunikasi tim

v Manajemen Risiko

• Mengidentifikasi dan me-review risiko- risiko kegagalan
• Mengembangkan perencanaan untuk mengurangi risiko ini

v Procurement management

• Mengembangkan permintaan proposal (RFPs)
• Mengevaluasi tawaran, menulis kontrak, memonitor performance

v Manajemen Integrasi

Permulaan Proyek dan Fase Perencanaan Proyek

v Mensinergikan kekuatan untuk memulai proyek

• Merespon kesempatan
• Memecahkan masalah
• Menyesuaikan diri terhadap petunjuk

v Inisiasi proyek berasal dari

• Perencanaan strategis IS jangka panjang (top-down) diprioritas dengan weighted scoring
• Para manager departemen atau manager proses (bottom-up)
• Merespon kekuatan- kekuatan luar (HIPAA)

Memulai Sistem Pendukung Pelanggan RMO

v Perencanaan IS strategis mengarahkan  prioritas proyek pengembangan IS

v Sistem pendukung pelanggan dipilih

• John MacMurty – creates project charter (membuat kesepakatan proyek)
• Barbara Halifax – project manager (manager proyek)
• Steven Deerfield – senior systems analyst (analis sistem senior)
• Goal is to support multiple types of customer services (ordering, returns, online catalogs) => Tujuan itu mendukung berbagai jenis layanan pelanggan (pemesanan, pengembalian, katalog online)

v Kesepakatan proyek menggambarkan partisipan-partisipan kunci (penting)

RMO Project Charter

Aktivitas fase perencanaan proyek

Aktivitas fase perencanaan proyek dan pertanyaan-pertanyaan kuncinya

Mendefinisikan Masalah

v Mereview kebutuhan-kebutuhan bisnis

• Menggunakan perencanaan strategis
• Mencari keterangan dari para user kunci
• Mengembangkan daftar dari keuntungan bisnis yang diharapkan

v Mengidentifikasi kemampuan sistem yang diharapkan

• Menentukan  skup istilah-istilah kebutuhan/persyaratan

v Membuat dokumen skup sistem

v Membangun bukti konsep prototype

v Diagaram konteks untuk Customer Support, slide 25

Mendefinisikan Masalah pada RMO

v  Barbara—menyelesaikan pernyataan definisi masalah

v Steve—memimpin persiapan penelitian pada solusi alternatif

v Barbara, Steve, dan William McDougal—memulai analisis sebelum membuat keputusan solusi

v Barbara dan Steve—memulai schedule, budget, pernyataan feasibiltas untuk sistem baru

Membuat Schedule Proyek

v Mengembankan work breakdown structure (WBS)

• Daftar tugas dan durasi yang dibutuhkan untuk proyek
• Mirip dengan outline untuk paper penelitian
• WBS adalah fondasi untuk schedule proyek

v Membangun grafik PERT/CPM

• Membantu dalam memberikan tugas
• Metode critical path
• Gantt chart dan tracking GANTT chart

Partial PERT/CPM Chart: slide 28

Gantt Chart for Entire Project (with overlapping phases): slide 29

Gantt Chart for Iterative Project: slide 30

Mengkonfirmasi Feasibilitas Proyek

v Manajemen Risiko

v Feasibilitas ekonomi

• Analisis biaya/keuntungan
• Sumber pendanaan (cash flow, lmodal jangka panjang)

v Organizational and cultural feasibility

v Technological feasibility

v Schedule feasibility

v Resource feasibility

Manajemen Risiko

Analisis Risiko yang Disempurnakan

Feasibilitas Ekonomi

v Analisis Cost/Benefit

• Menaksir biaya pengembangan proyek
• Menaksir biaya operasional setelah proyek
• Menaksir keuntungan finansial berdasarkan tabungan tahunan dan menambah pendapatan
• Menghitung dengan menggunakan tabel costs and benefits

v Menggunakan net present value (NPV), payback period, return on investment (ROI) techniques

Supporting Detail for Salaries and Wages for RMO, slide 34

Summary of Development Costs for RMO, slide 35

Summary of Annual Operating Costs for RMO, slide 36

Sample Benefits for RMO, slide 37

RMO Cost Benefit Analysis, slide 38

Intangibles dalam Feasibiltas Ekonomi

v Intangible benefits tidak dapat diukur dalam dollars

• Menambah level layanan
• Kepuasan pelanggan
• Survival
• Harus mengembangkan in-house expertise

v Intangible costs tidak dapat diukur dalam dollars

• Mengurangi moril pekerja
• Kehilangan produktivitas
• Kehilangan pelanggan atau penjualan

Feasibilitas Organisasi dan Kultur

v Tiap perusahaan memiliki kultur sendiri

• Sistem baru harus sesuai dengan kultur

v Mengevaluasi isu-isu terkait dengan risiko potensial

• Level bawah kompetensi komputer
• Fobi komputer
• Merasa kehilangan kontrol
• Berubah kemampuan
• Kekhawatiran perubahan kerja atau kehilangan kerja

Feasibilitas Teknologi

v Apakah sistem men-stretch state-of-the-art technology?

v Apakah in-house expertise sekarang ada untuk perkembangan?

v Apakah vendor luar harus dilibatkan?

v Solusi mencakup:

• Melatih dan menyewa para pekerja yang lebih berpengalaman
• Menyewa konsultan
• Mengubah skup dan pendekatan proyek

Feasibiltas Sumber Daya

v Ketersediaan anggota tim

v Level kemampuan tim

v Komputer, peralatan,  dan persediaan

v waktu dan ketersediaan staf pendukung

v Fasilitas Fisik

Staffing dan Launching Proyek

v Mengembangkan perencanaan sumber daya untuk proyek

v Mengidentifikasi dan meminta staf teknis khusus

v Mengidentifikasi dan meminta staf user khusus

v Mengorganisir tim proyek ke dalam workgroups

v Memimpin persiapan pelatihan dan latihan-latihan membangun tim

v Pertanyaan staffing kunci: “Apakah sumber daya tersedia, terlatih, dan siap untuk memulai (proyek)?”

Launching Project

v Skup didefinisikan, risiko diidentifikasi, proyek mungkin dapat dikerjakan, schedul dikembangkan, anggota tim diidentifikasi dan siap (bekerja)

v Oversight committee diselesaikan, bertemu untuk berjalan terus sebuah proyek, dan me-release keuangan

v Pengumuman formal dibuat untuk semua bagian yang terlibat dalam organisasi

v Pertanyaan launch kunci: “Apakah kita siap memulai?”

Ikhtisar Perencanaan Proyek RMO

v Membuat schedule dan perencanaan untuk CSS

v Menyebut semua aspek manajemen proyek (perencanaan dan skup proyek)

v Mencakup komunikasi dan kualitas proyek

v Mengidentifikasi anggota tim yang diinginkan

• Menyaring prosedur kerja internal
• Memikirkan alat dan teknik yang digunakan pada proyek
• Merencanakan meeting untuk peluncuran secara resmi

RINGKASAN

v Tugas Manajemen Proyek

• Mulai pada fase perencanaan proyek SDLC
• Melanjutkan ke tiap fase SDLC

v Mengorganisir dan memimpin orang lain

• Mencapai hasil yang direncanakan
• Menggunakan schedule dan budget yang ditetapkan sebelumnya

v Bidang Ilmu pengetahuan yang dibutuhkan

• Skup, waktu, biaya, kualitas, sumber daya manusia, komunikasi, risiko, procurement

v Inisiasi Proyek

• Kebutuhan sistem informasi diidentifikasi dan diprioritaskan dalam perencanaan strategis

v Fase Perencanaan  Proyek

• Mendefinisikan masalah (investigasi dan skup)
• Membuat schedule proyek (WBS)
• Mengkonfirmasi feasibiltas proyek (mengevaluasi proyek)
• Staff project (mengetahui skill orang)
• Launch project (persetujuan formal eksekutif)

Judul Buku: Systems Analysis and Design in a Changing World, Edisi 4

Penerjemah: Komarudin Tasdik

BAB 2 PENDEKATAN PENGEMBANGAN SISTEM

(Slide 1 s.d 3 berisi tujuan pembelajaran)

GAMBARAN UMUM

Proyek pengembangan sistem

• Direncanakan dengan awal dan akhir yang pasti (terencana)
• Memproduksi hasil atau produk yang diinginkan
• Bisa menjadi pekerjaan besar dengan istilah proyek thousands of hours of effort atau a small one-month

Proyek pengembangan yang sukses

• Menyediakan perencanaan detail untuk ditindaklanjuti
• Susunan pekerjaan dan aktivitas yang terorganisir dan metodis
• Memproduksi sistem yang handal, aman (robust), dan efficient

THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

Siklus Hidup Pengembangan Sistem (SDLC)

• Menyediakan kerangka menyeluru untuk memanage proses pengembangan sistem

Dua pendekatan utama SDLC

• Pendekatan prediktif: berasumsi bahwa proyek bisa direncanakan dengan matang (relatif sempurna di awal)
• Pendekatan adaptif: lebih fleksibel, berasumsi bahwa proyek tidak bisa direncanakan dengan matang (dari awal, sistem dianggap perlu pengembangan)

Semua proyek menggunakan beberapa varian SDLC

Memilih pendekatan SDLC prediktif atau adaptif: Lihat slide 6

PENDEKATAN PREDIKTIF TRADISIONAL SDLC

• Perencanaan proyek: menginisiasikan, memastikan feasibility, schedule, mendapatkan izin untuk proyek
• Analisis: memahami kebutuhan dan persyaratan proses bisnis
• Desain: menentukan sistem solutif berbasis keputusan syarat dan analisis
• Implementasi: membangung, menguji, melatih para user, dan meng-install sistem baru
• Support: memelihara dan mengembangkan sistem

Fase Pengembangan Sistem Informasi: lihat slide 8

SDLC DAN PENYELESAIAN MASALAH

Mirip dengan pendekatan penyelesaian masalah pada Bab 1

• Organisasi mengetahui masalah (perencanaan proyek)
• Tim proyek menginvestigasi, memahami masalah dan solusi yang dibutuhkan (analisis)
• Solusi ditentukan secara detail (desain)
• Sistem yang menyelesaikan masalah dibangun dan di-install (implementasi)
• Sistem digunakan, dipelihara, dan dikembangkan untuk memperoleh keuntungan yang diharapkan (support)

Pendekatan “Waterfal” SDLC: lihat slide 10

Pendekatan “Waterfal” yang dimodifikasi dengan fase overlapping: lihat slide 11

PENDEKATAN ADAPTIF BARU SDLC

Berbasis model spiral

• Siklus proyek dikembangkan terus hingga sempurna
• Prototype dibuat di akhir tiap siklus
• Fokus pada pengurangan risiko

Iterasi: aktivitas diulang

• Tiap iterasi melengkapi hasil sebelumnya
• Pendekatan berasumsi bahwa tidak ada yang langsung sempurna pada tahap pertama
• Terdapat seri proyek mini untuk tiap iterasi

Model siklus hidup Spiral: lihat slide 13

Iterasi aktivitas pengembangan sistem: lihat slide 14

Aktivitas tiap fase SDLC

• Pendekatan prediktif dan adaptif menggunakan SDLC
• Aktivitas tiap fase mirip
• Fase tidak selalu berurutan
• Fase bisa saling melengkapi (overlap)
• Aktivitas melintasi fase dapat dilakukan dalam iterasi

Aktivitas fase perencanaan SDLC

• Menentukan masalah dan skup bisnis
• Membuat schedule proyek detail
• Mengkonfirmasi feasibility proyek

Ekonomis, organisasional, teknis, sumber daya, dan schedule

• Mengangkat pegawai yang menjalankan proyek (manajemen sumber daya)
• Meluncurkan proyek (pengumuman resmi)

Aktivitas fase analisis SDLC

• Mengumpulkan informasi untuk mengkaji domain permasalahan
• Menentukan kebutuhan sistem
• Membangun protoype untuk menemukan kebutuhan
• Memprioritaskan kebutuhan
• Menghasilkan dan mengevaluasi alternatif
• Mereview rekomendasi dengan manajemen

Aktivitas fase desain SDLC

• Mendesain dan mengintegrasikan jaringan
• Mendesain arsitektur aplikasi
• Mendesain user interfaces
• Mendesain system interface
• Mendesain dan mengintegrasikan basis data
• Protype untuk design detail
• Mendesain dan mengintegrasikan system controls

Aktivitas fase implementasi SDLC

• Membangun komponen-komponen software
• Memverifikasi dan menguji
• Meng-convert (ubah) data
• Melatih user dan mendokumentasikan sistem
• Meng-install sistem

Aktivitas fase support SDLC

• Memelihara sistem

Menambal, memperbaiki, dan update ringan

• Mengembangkan sistem

–          Upgrade dan pengembangan ringan untuk meningkatkan kemampuan sistem

–          Pengembangan lebih besar mungkin membutuhkan proyek pengembangan terpisah

• Mendukung user

Membantu dan/atau mendukung tim utama

METODOLOGI DAN MODEL

Metodologi

• Panduan komprehensif untuk menyempurnakan setiap aktivitas SDLC
• Koleksi model, tools, dan teknik

Model

• Representasi aspek penting dunia nyata, meskipun tidak persis sama
• Abstraksi harus memisahkan aspek itu
• Diagram dan grafik
• Perencanaan proyek dan penganggaran bantuan

Beberapa model yang digunakan dalam pengembangan sistem: lihat slide 22

TOOLS DAN TEKNIK

Tools

• Software support yang membantu menciptakan model-model atau komponen-komponen proyek yang dibutuhkan
• Range dari program gambar sederhana hingga CASE tools kompleks untuk software manajemen proyek

Teknik

• Kumpulan panduan yang membantu analis menyempurnakan aktivitas atau tugas pengembangan sistem
• Bisa menjadi instruksi sedikit demi sedikit atau hanya saran umum

Beberapa tools yang digunakan dalam pengembangan sistem: lihat slide 24

Beberapa teknik yang digunakan dalam pengembangan sistem: lihat slide 25

Hubungan antar komponen dari sebuah metodologi: lihat slide 26

DUA PENDEKATAN PENGEMBANGAN SISTEM

Pendekatan Tradisional

• Disebut juga pengembangan sistem terstruktur
• Teknik analisis dan desain terstruktur (SADT)
• Mencakup information engineering (IE)

Pendekatan Berorientasi Objek

• Disebut juga OOA, OOD, dan OOP
• Memandang sistem informasi sebagai kumpulan objek saling berinteraksi yang bekerja bersama-sama untuk menyelesaikan tugas-tugas

Pendekatan Tradisional

• Mengembangkan kualitas program komputer
• Mengizikan para programmer lain dengan mudah membaca dan memodifikasi kode
• Tiap modul program memiliki awal dan akhir (yang jelas)

Tiga konstruksi pemrograman (susunan, keputusan, pengulangan)

Tiga konstruksi pemrograman terstruktur: lihat slide 29

Pemrograman Top-Down

• Membagi program-program kompleks ke dalam hirarki modul-modul
• Modul pada eksekusi modul atas dengan memanggil modul-modul level bawah
• Pemrograman modular

Mirip dengan pemrograman top-down

• Satu program memanggil program-program lain untuk bekerja bersama-sama sebagai sistem tunggal

Pemrograman Top-Down atau Modular: slide 31

Desain terstruktur

Teknik dikembangkan untuk menyediakan panduan desain

• Kumpulan program apa yang harus dibangun
• Program apa yang harus disempurnakan
• Bagaimana program diorganisir ke dalam sebuah hirarki

Modul ditampilkan dengan structure chart

Prinsip utama modul program

• Loosely coupled: modul independen dari modul-modul lain
• Highly cohesive: modul memiliki satu tugas jelas

Structure chart dibuat menggunakan teknik desain terstruktur: lihat slide 33

Analisis terstruktur

• Menentukan sistem apa yang harus melakukan (syarat pemrosesan)
• Menentukan sistem data yang harus menyimpan dan menggunakan (kebutuhan data)
• Menentukan input dan output
• Menentukan bagaimana fungsi-fungsi bekerja sama menyempurnakan tugas-tugas
• Data Flow Diagrams (DFD) dan Entity Relationship Diagrams (ERD) memperlihatkan hasil analisis terstruktur

Data Flow Diagram (DFD) dibuat menggunakan teknik analisis terstruktur: lihat slide 35

Entity-Relationship Diagram (ERD) dibuat menggunakan teknik analisis terstruktur: slide 36

Analisis terstruktur menuju desain dan pemrograman terstruktur: slide 37

Information Engineering (IE)

• Perbaikan terhadap pengembangan terstruktur
• Metodologi dengan perencanaan strategis, pemodelan data, fokus tools otomatis
• Lebih teliti dan lengkap daripada SADT
• Industri menggabungkan konsep-konsep kunci dari pengembangan terstruktur dan pendekatan-pendekatan information engineering ke dalam pendekatan tradisional

PENDEKATAN BERORIENTASI OBJEK

Pendekatan sistem informasi yang sangat berbeda

Menampilkan sistem informasi sebagai kumpulan objek yang berinteraksi bekerja sama untuk menyelesaikan tugas-tugas

• Objek: sesuatu dalam sistem komputer yang dapat merespon pesan
• Secara konseptual, bukan proses, program, entitas data, atau file yang ditetapkan—hanya objek
• OO languages (bahasa berorientasi objek): Java, C++, C# .NET, VB .NET

Pendekatan Berorientasi Objek Sistem: slide 40

PENDEKATAN BERORIENTASI OBJEK

• Analisis berorientasi objek (OOA)

–          Menentukan jenis-jenis objek berdasarkan kebutuhan user

–          Memperlihatkan kasus-kasus penggunaan yang dibutuhkan untuk menyelesaikan tugas/pekerjaan

• Desain berorientasi objek (OOD)

–          Menentukan jenis-jenis objek yang harus berkomunikasi dengan orang dan perangkat dalam sistem

–          Menampilkan bagaimana objek-objek berinteraksi untuk menyelesaikan pekerjaan

–          Menentukan tiap jenis objek untuk implementasi dengan bahasa khusus lingkungan

• Pemrograman berorientasi objek (OOP)

–          Menulis pernyataan dalam bahasa pemrograman untuk menentukan jenis objek apa yang melakukan

Class Diagram dibuat selama analisis OO: slide 42

Variasi SDLC

Beberapa varian SDLC dalam praktek

• Berdasarkan varian nama fase
• Tidak masalah aktivitas/tugas mana yang mirip

Perhatian tambahan pada orang

• User-centered design, participatory design
• Sociotechnical systems

Kecepatan tambahan pengembangan

• Pengembangan aplikasi cepat (RAD)
• Prototyping

Siklus hidup dengan nama fase berbeda: slide 44

Trend baru dalam pengembangan

• Lebih banyak pendekatan adaptif

v  The Unified Process (UP)

v  Extreme Programming (XP)

v  Agile Modeling

v  Scrum

• Detailnya pada bab 16

The Unified Process (UP)

• Pendekatan pengembangan berorientasi objek
• Ditawarkan oleh IBM/rational

–          Booch, Rumbaugh, Jacobson

• Unified Modeling Language (UML) digunakan terutama untuk pemodelan
• UML bisa digunakan dengan teknologi OO apapun
• UP menentukan empat fase siklus hidup

Insepsi, elbaorasi, konstruksi, transisi

• Menguatkan enam praktek terbaik

–          Berkembang secara iteratif

–          Menentukan dan memanage kebutuhan sistem

–          Menggunakan arsitektur-arsitektur komponen

–          Menciptakan model-model visual

–          Memverifikasi model

–          Mengontrol perubahan-perubahan

Extreme Programming (XP)

• Baru, ringan, pendekatan pengembangan untuk menjaga penyederhanaan dan efisiensi proses
• Mendeskripsikan system support yang dibutuhkan dan diminta fungsionalitas sistem melalui cerita-cerita user informal
• Memiliki user untuk mendeskripsikan uji penerimaan/kelayakan untuk mendemonstrasikan hasil yang telah ditetapkan
• Bergantung pada testing dan integrasi berkelanjutan, sangat melibatkan user, pemrograman dilakukan oleh tim kecil

Agile Modeling

• Hybrid of XP and UP (Scott Ambler); memiliki model lebih banyak dari XP, dokumen lebih sedikit daripada UP
• Pemodelan interaktif dan inkremental

–          Menggunakan mode yang benar

–          Membuat beberapa model paralel

–          Model dalam inkremen-inkremen kecil

• Kerja tim

–          Mendapatkan partisipasi stakeholder yang aktif

–          Mendorong kepemilikan kolektif

–          Model dengan yang lainnya dan menampilkan model ke publik

• Kesederhanaan

–          Menggunakan isi sederhana

–          Menggambarkan sistem secara sederhana

–          Menggunakan tools pemodelan yang sangat sederhana

• Validasi

–          Mempertimbangkan uji kemampuan

–          Membuktikan model yang benar dengan kode

Scrum

• Untuk keperluan proyek adaptif tinggi
• Merespon situasi secepat mungkin
• Scrum mengacu pada rugby game

–          Keduanya cepat, cerdas, dan mengorganisir sendiri

–          Tim memelihara kontrol terhadap proyek

–          Nilai-nilai perorangan di atas proses

Tools untuk mendukung pengembangan sistem

• Computer-aided system engineering (CASE)

–          Tools otomatis untuk meningkatkan kecepatan dan kualitas pekerjaan pengembangan sistem

–          Memiliki database informasi tentang sistem yang disebut repository

• Upper CASE – mendukung analisis dan desain
• Lower CASE – mendukung implementasi
• ICASE – CASE Tools yang terintegrasi
• Sekarang disebut alat pemodelan visual, alat pengembangan aplikasi terintegrasi, dan round-trip engineering tools

CASE Tool Repository memiliki semua informasi sistem

RANGKUMAN

• Proyek pengembangan sistem diorganisir di sekitar siklus hidup pengembangan sistem  (SDLC)
• Beberapa proyek menggunakan pendekatan prediktif  SDLC, dan yang lainnya lebih banyak menggunakan pendekatan adaptif SDLC
• Fase SDLC mencakup perencanaan proyek, analisis, desain, implementasi, dan support
• Dalam prakteknya, overlap fase, dan proyek memiliki beberapa iterasi analisis, desain, dan implementasi
• Model, teknik, dan tools mendukung teknologi pengembangan sistem
• Metodologi pengembangan sistem menyediakan panduan untuk menyempurnakan setiap aktivitas dalam SDLC
• Metodologi-metodologi pengembangan sistem itu berbasiskan pendekatan tradisional atau pendekatan berorientasi objek
• Trend baru mencakup: Extreme Programming (XP), Unified Process (UP), Agile Modeling, dan Scrum
• CASE tools didesain untuk membantu para analis menyelesaikan tugas-tugas/pekerjaan pengembangan sistem

TERJEMAHAN INI BELUM DIEDIT

Sumedang, 4 September 2010

Judul Buku: Systems Analysis and Design in a Changing World, Edisi 4

Bab I Dunia Analis Sistem Informasi

(Slide 1 s.d 3 berisi tujuan pembelajaran)

GAMBARAN UMUM

Sistem Informasi

• Krusial untuk kesuksesan organisasi bisnis modern
• Secara konstant dikembangkan untuk menjadikan bisnis lebih kompetitif
• Mempengaruhi produktivitas dan keuntungan

Kunci Pengembangan Sistem yang Sukses

• Analisis dan desain sistem yang cermat
• Memahami kebutuhan bisnis/perusahaan

Analisis Sistem: proses pemahaman detail tentang sistem yang harus disempurnakan.

Desain Sistem: proses penentuan detail bagaimana komponen-komponen sistem informasi harus diimplementasikan secara fisik.

Analis Sistem: menggunakan teknik-teknik analisis dan desain untuk menyelesaikan masalah bisnis menggunakan teknologi informasi.

Analis sebagai Penyelesai Masalah Bisnis

• Memiliki pengetahuan tentang teknologi komputer dan keahlian pemrograman
• Memahami permasalahn bisnis
• Menggunakan metode logis untuk menyelesaikan masalah
• Memiliki kenginantahu secara fundamental
• Ingin membuat sesuatu yang lebih baik
• Cenderung pada penyelesai masalah bisnis daripada pemrogram teknis

Pendekatan Analis untuk Penyelesaian Masalah

• Meneliti dan memahami masalah
• Memverifikasi manfaat cenderung pada penyelesaian masalah daripada biaya
• Menentukan keperluan untuk menyelesaian masalah
• Mengembangkan sejumlah solusi alternatif
• Memutuskan solusi terbaik dan yang direkomendasikan
• Menentukan detail solusi yang dipilih
• Mengimplementasikan solusi
• Memonitor untuk memastikan hasil-hasil yang diinginkan

Sistem yang Menyelesaikan Masalah Bisnis

• Sistem: komponen-komponen yang saling terhubung, berfungsi bersama-sama untuk mencapai hasil
• Sistem informasi: kumpulan komponen-komponen yang saling terhubung; mengumpulkan, memproses, menyimpan, dan menyedian informasi yang dibutuhkan untuk membantu penyelesaian pekerjaan.
• Subsistem: bagian dari sistem
• Supersistem: sistem sangat besar yang memiliki subsistem- subsistem
• Dekomposisi fungsional: membagi sistem kepada beberapa subsistem dan komponen yang lebih kecil.

Sistem Informasi dan Subsistemnya: lihat gambar di slide 9

Sistem Informasi dan Komponennnya: lihat gambar di slide 10

Batas Sistem v.s. Batas Otomatisasi: lihat gambar di slide 11

Jenis-Jenis Sistem Informasi:

• Sistem Pemrosesan Transaksi (TPS)

Mendapatkan dan merekam informasi tentang transaksi organisasi

• Sistem Informasi Manajemen (MIS)

–          Mengambil informasi yang didapatkan oleh TPS

–          Memproduksi laporan perencanaan dan pengawasan

• Sistem Pendukung Keputusan/Sistem berbasis Pengetahuan (DSS/KBS)

–          Menyelediki dampak dari pilihan dan keputusan yang ada (Skenario What-If)

–          Mengotomatisasi pembuatan keputusan rutin

• Aplikasi Perusahaan

–          Sistem terintegrasi tinggi yang mendukung operasi dan data besar perusahaan

–          Sering mengkombinasikan aspek-aspek: TPS, MIS, DSS/KBS

• Sistem Pendukung Komunikasi

Memfasilitasi komunikasi secara internal dengan para pelanggan dan para supplier

• Sistem Pendukung Kantor

Membantu para pekerja membuat dan berbagi dokumen

Jenis Sistem Informasi: lihat gambar di slide 14

Skill yang Dibutuhkan oleh Analis Sistem: lihat gambar di slide 15

PENGETAHUAN DAN SKILL TEKNIS

Analis Sistem harus memiliki pengetahuan teknologi fundamental:

• Komputer/periferal (hardware)
• Jaringan komunikasi dan konektivitasnya
• Basis Data dan Database Management Systems (DBMS)
• Bahasa-bahasa pemrograman (contohnya: VB.NET atau Java)
• Sistem operasi dan utilitas

Analis menggunakan tools

• Paket produktivitas software
• Integrated Development Environments (IDEs) untuk bahasa pemrograman
• CASE tools, testing, pendukung dokumentasi, reverse engineering, manajemen konfigurasi

Analis memahami teknik-teknik SDLC:

• Perencanaan proyek, analisis sistem
• Desain sistem, desain basis data, desain jaringan
• Konstruksi, implementasi, dan pendukung sistem

PENGETAHUAN DAN SKILL BISNIS

Analis harus memahami

• Fungsi-fungsi bisnis yang dijalankan oleh organisasi
• Berbagai strategi, perencanaan, tradisi, dan nilai dari organisasi
• Struktur organisasi
• Teknik-teknik manajemen organisasi
• Proses-fungsi pekerjaan fungsional

Analis sistes khusus mengkaji administrasi/manajemen bisnis di perguruan tinggi pada matakuliah CIS atau MIS

PENGETAHUAN DAN SKILL SOSIAL

Analis sistem harus memahami bagaimana orang:

• Berpikir
• Belajar
• Bereaksi terhadap perubahan
• Berkomunikasi
• Bekerja (dalam berbagai pekerjaan dan level)

Skill interpersonal dan komunikasi krusial untuk

• Memperoleh informasi
• Memotivasi orang
• Mendapatkan kerja sama (bekerja sama)
• Memahami kompleksitas dan pekerjaan-pekerjaan organisasi untuk menyediakan pendukung yang dibutuhkan

INTEGRITAS DAN ETIKA

Analis memiliki akses terhadap informasi rahasia, seperti gaji, proyek yang direncanakan organisasi, sistem keamanan, dan lain-lain.

• Harus menjaga kerahasiaan informasi
• Beberapa ketidaklayakan dapat merusakan karir analis
• Analis merencanakan keamanan dalam sistem untuk memproteksi informasi rahasia

LINGKUNGAN DI SEKITAS ANALIS

Jenis-jenis teknologi mencakup:

• Desktop
• Networked Desktop
• Client-server
• Mainframe sentralistik dalam skala besar
• Internet, intranet, dan ekstranet
• Wireless, PDA/Cell phones, mobile desktops

PENGGUNAAN TEKNOLOGI WEB UNTUK FLEKSIBILITAS

Aplikasi-aplikasi membutuhkan lingkungan pengembangan fleksibel

• Akses di mana saja, kapan saja
• Untuk para karyawan, partner, dan pelanggan

Sangat baik disediakan dengan teknologi berbasis web

• B2C: Business to Consumer
• B2B: Business to Business

JENIS DAN TEMPAT PEKERJAAN KHUSUS

Jenis pekerjaan analis sistem sangat berbeda, tapi memerlukan hal yang sama

Tempat bekerja berbeda mulai bisnis/perusahaan kecil hingga perusahaan besar

Analis bisa menjadi karyawan internal atau konsultan luar

Analis dapat mengembangkan solusi-solusi untuk para manager internal atau untuk para klien dan pelanggan eksternal

PERAN ANALIS DALAM PERENCANAAN STRATEGIS

Proyek khusus mempengaruhi eksekutif

• Reengineering proses bisnis—perubahan radikal untuk proses-proses yang ada

Proses perencanaan strategis

Perencanaan strategis sistem informasi

• Perencanaan arsitektur aplikasi (fokus bisnis)
• Perencanaan arsitektur teknologi (fokus infrastruktur)

Perencanaan sumberdaya perusahaan (ERP)

Komponen-komponen perencanaan strategis sistem informasi: lihat gambar di slide 26

ROCKY MOUNTAIN OUTFITTERS (RMO) DAN PERENCANAAN SISTEM INFORMASI STRATEGISNYA

• Manufacturer dan distributor pakaian olahraga RMO mulai membuat proyek sistem pendukung pelanggan
• Harus memahami sifat bisnis, pendekatan terhadap perencanaan strategis, dan tujuan sistem pendukung pelanggan
• Proyek pengembangan sistem RMO harus mendemonstrasikan konsep analisis dan desain
• Reliable Pharmaceutical Service (RPS) adalah studi kasus kedua untuk tujuan-tujuan pembelajaran

Pengenalan terhadap Bisnis RMO

• Berdiri di Park City, Utah menyediakan pakaian olahraga musim dingin untuk toko ski lokal
• Diekspansi ke dalam penjualan mail-order langsung dengan katalog kecil—mengingat kebutuhan katalog bertambah, maka dibuat toko retail terbuka di Park City, distribusi pakaian olahraga regional awalnya dilakukan oleh 2000 distributor di Rocky Mountain dan Western States
• Sekarang penjualan tahunan berkisar $150 juta, 600 karyawan, dan dua toko retail
• Penghasilan mail-order berkisar $90 juta; penghasilan phone-order berkisar $50 juta

Cover katalog RMO awal (1978): lihat gambar di slide 29

Cover katalog RMO sekarang (2007): lihat gambar di slide 30

ISU-ISU STRATEGIS RMO

• Distributor pakaian yang inovatif; produk-produk unggulan terpasang di website mendahulu para pesaing
• Fungsi-fungsi website asli

–          meningkatkan image, copian permintaan katalog, portal terhadap website sport outdoor

• meningkatkan fungsi-fungsi website

–          menambah informasi produk khusus, spesial mingguan, dan semua penawaran produk

• perencanaan strategis IS detail

–          manajemen rantai persediaan

–          manajemen hubungan pelanggan

STRUKTUR ORGANISASI RMO

Dimanage oleh original owners

• John Blankens – President
• Liz Blankens – Vice president of merchandising and distribution
• William McDougal – Vice president of marketing and sales
• JoAnn White – Vice president of finance and systems

Lata belakang keuangan dan accounting

Lokasi RMO: lihat gambar di slide 33

DEPARTEMEN SISTEM INFORMASI RMO

• Mac Preston – Assistant vice-president and chief information officer (CIO)
• Promosi baru dibuat setelah pembuatan perencanaan strategis IS
• Laporan CIO untuk keuangan dan systems VP
• CIO semakin penting bagi masa depan RMO
• Kepentingan strategisnya yang diberikan, departemen IS akan melaporkannya kepada CEO
• Staf departemen SI RMO: lihat gambar di slide 35

Sistem ROM yang ada

• Sistem berbasis mainframe kecil

–          Inventori pendukung, mail-order, accounting, dan sumberdaya manusia

–          Memiliki konektivitas resmi untuk situs distribusi dan mail-order

• LANs and file servers

–          Mendukung fungsi kantor central, pusat distribusi, dan pusat-pusat manufacturing

–          Batch updates ke mainframe

• Website informasi RMO

–          Hosted by oleh Internet service provider (ISP)

• Merchandising/distribution system

Mainframe berumur 12 tahun: COBOL/CICS, DB2, VSAM application

• Mail order system

Mainframe COBOL application berumur 14 tahun

• Phone order system

Oracle and Visual Basic system built 6 tahun yang lalu

• Retail store systems

Point-of-sale dan paket invonetori batch berumur 8 tahun, update semalam dengan mainframe

• Office systems

LAN dengan office software, Internet, e-mail

• Sumber daya manusia

Daftar gaji dan benefit berbasis mainframe berumur 13 tahun

• Accounting/finance system

Paket mainframe dibeli dari vendor terkenal

PERENCANAAN STRATEGIS SI

Mendukung perencanaan strategis RMO

• Membangun hubungan pelanggan langsung lebih banyak
• Memperluas pemasaran ke luar Western states

Perencanaan bersifat seri untuk pengembangan dan proyek integrasi sistem informasi selama beberapa tahun

Peluncuran proyek: sistem pendukung pelanggan baru untuk mengintegrasi orderan telpon, surat, dan orderan pelanggan langsung via internet

PERENCANAAN ARSITEKTUR TEKNOLOGI RMO

Aplikasi bisnis distribusi

• Melintasi berbagai lokasi dan sistem
• Menyediakan mainframe untuk web server, databse, dan telekomunikasi

Proses bisnis strategis via internet

• Manajemen rantai persediaan (SCM)
• Pemesanan pelanggan langsung via website dinamis
• Manajemen hubungan pelanggan (CRM)
• Intranet berbasis web untuk pekerjaan-pekerjaan bisnis

PERENCANAAN ARSITEKTUR APLIKASI RMO

Supply chain management (SCM)

• Pengembangan produk, penambahan produk, manufacturing, dan manajemen inventori

Customer support system (CSS)

• Mengintegrasikan sistem pemrosesan dan pemenuhan order dengan SCM
• Mendukung order pelanggan (surat, telpon, web)

Sistem manajemen informasi strategis

• Mengekstrak dan menganalisis informasi SCM dan CSS untuk pembuatan dan pengawasan keputusan operasional dan strategis

Retail store system (RSS)

• Mengganti sistem penyimpanan ritel yang ada dengan sistem yang terintegrasi dengan CSS

Accounting/finance system

• Aplikasi intranet pembelian untuk memaksimalkan akses karyawan terhadap perencanaan dan pengawasan data keuangan

Sistem sumber daya manusia (HR)

• Aplikasi intranet pembelian untuk memaksimalkan akses karyawan terhadap informasi kondisi sumber daya manusia, prosedur, dan keuntungan

Daftar Perencanaan Strategis RMO: lihat gambar di slide 43

The Customer Support System (CSS)

• Kompetensi inti RMO adalah kemampuannya mengembangkan dan memlihara loyalitas pelanggan
• Supply chain management (SCM) harus ditentukan sebelum CSS dimulai
• CSS adalah sistem inti yang mendukung manajemen hubungan pelanggan
• Aktivitas analisis sistem akan menentukan kebutuhan sistem secara detail
• Tujuan-tujuan yang tercantum pada perencanaan strategis akan menjadi pedoman sebagai hasil proyek

Analis sebagai Pengembang Sistem (System Developer)

Bagian 1: Analis Sistem

• Bab 1: Dunia Analis Sistem Informasi (bab ini)
• Bab 2: Pendekatan Pengembangan Sistem

–          SDCLC yang prediktif dan adaptif

–          Pendekatan tradisional

–          Pendekatan berorientasi objek

• Bab 3: Analis sebagai manager proyek

Bagian 2: Tugas Analis Sistem

• Bab 4: Memulai Analisis: Kebutuhan Sistem Investigasi
• Bab 5: Kebutuhan Sistem Modeling
• Bab 6: Pendekatan Tradisional terhadap Kebutuhan
• Bab 7: Pendekatan Berorientasi Objek terhadap Kebutuhan
• Bab 8: Mengevaluasi Alternatif untuk Kebutuhan, Lingkungan, dan Implementasi
• Bagian 3: Tugas Desain Sistem
• Bab 9: Menuju Desain
• Bab 10: Pendekatan Tradisional terhadap Desain
• Bab 11: Pendekatan Berorientasi Objek terhadap Desain
• Bab 12: Mendesain Database
• Bab 13: Mendesain User Interface
• Bab 14: Mendesain Interface, Kontrol, dan Keamanan Sistem

Bagian 4: Implementasi dan Support

• Bab 15: Membuat Operasional Sistem
• Bab 16: Trend Terbaru dalam Pengembangan Sistem

Bab Tambahan Online

• Online Bab 1: Topik Lanjutan dalam Desain OO
• Online Bab 2: Paket Software dan ERP

Lampiran Online

• Manajemen Proyek, Keuangan, Perencanaan, Interviewing

RANGKUMAN

• Analis sistem menyelesaikan permasalahan bisnis menggunakan teknologi sistem informasi
• Penyelesaian masalah berarti melihat permasalahan bisnis secara detail, sangat memahami masalah, dan memilih solusi terbaik
• Pengembangan sistem informasi lebih diutamakan daripada penulisan program
• Sistem—kumpulan komponen-komponen yang terhubung, berfungsi bersama-sama untuk mencapai suatu hasil
• Hasil sistem informasi—solusi untuk masalah bisnis
• Sistem informasi, subsistem, dan komponen-komponennya berinteraksi dengan dan mencakup hardware, software, input, output, data, manusia, dan prosedur
• Analis sistem memiliki pengetahuan luas dan berbagai keahlian, mencakup teknis, bisnis, dan sosial
• Perilaku integritas dan etis krusial untuk kesuksesan analis
• Analis sistem mengimbangi berbagai teknologi perubahan cepat
• Pekerjaan analis sistem pada perencanaan strategis dan kemudian pada proyek pengembangan sistem

Diterjemahkan dari materi pertemuan 1 matakuliah ADS (Analisis dan Desain Sistem) oleh Komarudin Tasdik

TERJEMAHAN INI BELUM DI EDIT

Sumedang, 30 Agustus 2010