RPL4 - System Engineering

25
SYSTEM ENGINEERING

Transcript of RPL4 - System Engineering

Page 1: RPL4 - System Engineering

SYSTEM ENGINEERING

Page 2: RPL4 - System Engineering

2

System Engineering Rekayasa perangkat lunak terjadi sebagai konsekwensi

dari suatu proses yang disebut rekayasa sistem Rekayasa sistem memfokuskan diri pada berbagai

elemen, analisis, desain, dan pengorganisasian elemen-elemen tersebut ke dalam suatu sistem yang dapat menjadi sebuah produk, jasa atau teknologi untuk mentransformasi informasi atau kontrol

Proses rekayasa sistem disebut rekayasa informasi bila konteks kerja berfokus pada perusahaan bisnis.

Pada saat produk akan dibuat, proses ini disebut rekayasa produk

Baik rekayasa informasi maupun rekayasa produk, keduanya cenderung kepada pengembangan sistem berbasis komputer.

Page 3: RPL4 - System Engineering

3

Computer-based System Definisi sistem berbasis komputer menurut Webster’s

Dictionary: Serangkaian atau tatanan elemen-elemen yang diatur untuk

mencapai tujuan yang ditentukan sebelumnya melalui pemrosesan informasi.

Tujuannya adalah untuk mendukung berbagai fungsi bisnis atau untuk mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis.

Elemen-elemen sistem berbasis komputer: Perangkat lunak (program komputer, struktur data dan dokumen

yang berhubungan) Perangkat keras (perangkat elektronik dan elektromekanik) Manusia (user yang memakai perangkat lunak dan perangkat

keras) Database (kumpulan informasi besar dan terorganisir yang

diakses melalui perangkat lunak) Dokumentasi (manual, formulir, dan informasi deskriptif lainnya) Prosedur (langkah-langkah konteks prosedural dari sistem)

Page 4: RPL4 - System Engineering

4

Sistem Dari Banyak Sistem

Sistem Otomasi Pabrik

Sistem Pemanukfaturan

Sel PemanufakturanSistem Aliran Material

Perangkat Entry DataRobotMesin Control Numeric

Sistem InformasiSistem Inventori

Page 5: RPL4 - System Engineering

5

Hirarki Rekayasa Sistem Rekayasa melingkupi sekumpulan metode dari atas ke bawah (top-

down) dan dari atas ke bawah (bottom-up) untuk mengendalikan hirarki dari sistem makro.

Proses rekayasa sistem dimulai dengan sebuah world view (WV), yaitu di mana semua domain bisnis atau domain produk diuji untuk memastikan bahwa bisnis atau konteks teknologi yang tepat dapat dibangun

Pada domain tertentu (interest), kebutuhan sistem yang ditargetkan (mis. data, S/W, H/W, manusia) dianalisis, kemudian dilakukan analisis, desain, dan kontruksi dari elemen yang ditargetkan diinisiasi.

Pada puncak hirarki, suatu konteks yang lebih luas dibangun, dan di bagian dasarnya, aktivitas teknik lengkap yang dilakukan oleh disiplin rekayasa yang relevan dilakukan.

Gambaran sistem : WV = {D1 D2 D3……Dn} WV = wold view (sebuah sistem besar)Di = {E1 E2 E3……En} Di = domain sistem (sub sistem)E1 = {C1 C2 C3……Cn} Ei = elemen (pembentuk domain)

Page 6: RPL4 - System Engineering

6

Hirarki Rekayasa Perangkat Lunak

Domain Bisnis (Produk)

domain interes

World View

elemen sistemPandangan Domain

Pandangan Elemen

Pandangan Detail

Page 7: RPL4 - System Engineering

7

Rekayasa Informasi

Tujuan dari rekayasa informasi (information engineering) adalah untuk menentukan arsitektur yang memungkinkan suatu bisnis menggunakan

informasi secara efektif. membuat suatu rencana menyeluruh guna mengimplementasi

arsitektur-arsitektur tersebut Tiga arsitektur yang harus dianalisis dan dirancang di

dalam konteks dan tujuan bisnis: arsitektur data : memberikan kerangka kerja untuk kebutuhan

informasi dan bisnis atau fungsi bisnis. Blok bangunan dari arsitektur ini adalah objek data yang digunakan oleh suatu database dan ditransformasikan untuk memberikan informasi yang melayani kebutuhan bisnis

arsitektur aplikasi : melingkupi elemen-elemen dari suatu sistem yang mentransformasi objek ke dalam arsitektur data untuk keperluan bisnis

infrastruktur teknologi : menyangkut perangkat keras dan perangkat lunak yang digunakan untuk mendukung aplikasi dan data.

Page 8: RPL4 - System Engineering

8

Rekayasa Informasi Untuk memodelkan arsitektur sistem, ditetapkan hirarki aktivitas

rekayasa informasi, mulai dari World View, Domain View, Element View hingga Detail View

WV dicapai melalui information strategy planning (ISP), dengan memandang bisnis keseluruhan sebagai sebuah entitas dan memisahkan domain bisnis yang penting untuk perusahaan keseluruhan

Pandangan domain yang dikaitkan dengan IE disebut analisis area bisnis/ Business Area Analysis (BAA)

BAA adalah pengindentifikasian data lengkap dan persyaratan fungsi (dalam bentuk proses) dari area bisnis yang dipilih, yang diindentifikasi selama ISP, dan memastikan interaksi mereka.

BAA mendefinisikan objek-objek data, hubungan mereka, dan bagaimana data mengalir.

Page 9: RPL4 - System Engineering

9

Hirarki Rekayasa Informasi

Perusahaan

Sistem Informasi

Area Bisnis

Perencanaan Strategi Informasi (World View)

persyaratan pemrosesan

Analisis Area Bisnis(Pandangan Domain)

Desain Sistem Bisnis(Pandangan Elemen)

Konstruksi dan Integrasi (Pandangan Detail)

area bisnis

Perekayasa Perangkat Lunak

Page 10: RPL4 - System Engineering

10

Analisis Area Bisnis Dalam bukunya tentang Sistem Informasi, James Martin menggambarkan

analisis area bisnis sebagai berikut: BAA membentuk suatu kerangka kerja lengkap untuk membangun

perusahaan yang berbasis informasi. BAA menggunakan satu area bisnis pada suatu waktu dan

menganalisisnya secara detail. BAA menggunakan diagram dan matriks untuk memodelkan dan

merekam data dan aktivitas pada perusahaan dan memberikan pemahaman yang jelas terhadap cara yang diteliti dan cerdik di mana aspek informasi dari perusahaan saling berhubungan.

Untuk memodelkan aspek informasi saling berhubungan, perekayasa informasi harus menggambarkan bagaimana objek data digunakan dan ditransformasikan pada masing-masing area bisnis dan bagaimana fungsi-fungsi dan proses bisnis pada masing-masing area bisnis itu mentransformasi objek data tersebut.

Untuk melakukan tersebut, BAA menggunakan sejumlah model: model data model aliran proses diagram dekomposisi proses matriks lintas referensi

Page 11: RPL4 - System Engineering

11

Pemodelan Data Objek : Pelanggan Atribut :

nama nama perusahaan objek : perusahaan klasifikasi pekerjaan dan otoritas pembelian alamat bisnis dan informasi kontak pembelian sebelumnya tanggal kontak terakhir rekaman kontak status kontak status kontak terakhir

tanggal kontak selanjutnya sifat kontak yang disepakati

Atribut nama perusahaan dimodifikasi untuk menunjuk objek lain yang disebut perusahaan, yang dapat berisi informasi tambahan mengenai besar perusahaan, kebutuhan pembelian, nama kontak yang lain, dsb., yang berguna dalam domain penjualan.

Page 12: RPL4 - System Engineering

12

Pemodelan Proses Kerja yang dilakukan pada suatu area bisnis mencakup

serangkaian fungsi bisnis, yang disaring ke dalam proses bisnis

Contoh : proses yang tersaji dalam penjualan membangun kontak pelanggan menyediakan literatur dan informasi yang sesuai mengarahkan pertanyaan dan perhatian memberi evaluasi produk menerima pesanan penjualan memeriksa ketersediaan konfigurasi yang dipesan menyiapkan pesanan pengiriman mengkonfirmasikan konfigurasi, penetapan harga, tanggal

pengiriman pada pelanggan mengirim pesanan pengiriman ke bagian pengiriman tindak lanjut dengan pelanggan

Page 13: RPL4 - System Engineering

13

Pemodelan Aliran Informasi Model aliran proses diintegrasikan dengan model data untuk

mengindikasi bagaimana informasi mengalir melalui suatu area bisnis.

Objek data input dan output yang diperlihatkan untuk masing-masing proses menunjukkan bagaimana proses mentransformasi informasi untuk menyelesaikan suatu fungsi bisnis

Membangunkontak

pelanggan

Membangunkontak

pelanggan

Memberiproduk

informasi

Memberiproduk

informasi

MemberiEvaluasiproduk

MemberiEvaluasiproduk

MengarahkanPertanyaan/perhatian

MengarahkanPertanyaan/perhatian

MenerimaPesanan

penjualan

MenerimaPesanan

penjualan

MemeriksaKonfigurasi

ketersediaan

MemeriksaKonfigurasi

ketersediaan

MenyiapkanPesanan

pengiriman

MenyiapkanPesanan

pengiriman

Mengkonfir-masikan Info

pesanan

Mengkonfir-masikan Info

pesanan

MembangunKontak

pelanggan

MembangunKontak

pelanggan

Tindak lanjutdengan

pelanggan

Tindak lanjutdengan

pelangganModel aliran proses untuk fungsi penjualan

Page 14: RPL4 - System Engineering

14

Pemodelan Aliran Informasi

Membangunkontak

pelanggan

Membangunkontak

pelanggan

Memberiproduk

informasi

Memberiproduk

informasi

MemberiEvaluasiprduk

MemberiEvaluasiprduk

MengarahkanPertanyaan/perhatian

MengarahkanPertanyaan/perhatian

MenerimaPesanan

penjualan

MenerimaPesanan

penjualan

MemeriksaKonfigurasi

ketersediaan

MemeriksaKonfigurasi

ketersediaan

MenyiapkanPesanan

pengiriman

MenyiapkanPesanan

pengiriman

Mengkonfir-masikan Info

pesanan

Mengkonfir-masikan Info

pesanan

MembangunKontak

pelanggan

MembangunKontak

pelanggan

Tindak lanjutdengan

pelanggan

Tindak lanjutdengan

pelanggan

Menambahkan aliran informasi pada model aliran proses untuk fungsi penjualan

Rekamankontak

Infoproduk

Deskripsiproduk

Pemenuhanpesanan

Deskripsiproduk

Pelanggan

Pemenuhanpesanan

konfigurasiketersediaan

Info pesanan

MengirimInfo pesanan

Pesananpengiriman

Pemenuhanpesanan

Info pesanan

query pesanan

Page 15: RPL4 - System Engineering

15

Rekayasa Produk

Rekayasa produk (rekayasa sistem) merupakan suatu aktivitas pemecahan masalah.

Data produk, fungsi, dan tingkah laku yang diinginkan ditemukan, dianalisis, dan dialokasikan ke dalam komponen rekayasa individu.

Asal dari sebagian besar produk dan sistem baru dimulai dengan konsep yang samar-samar dari fungsi yang dibutuhkan.

Perekayasa sistem harus membatasi persyaratan produk dengan mengindentifikasi ruang lingkup fungsi dan kinerja yang diinginkan.

Page 16: RPL4 - System Engineering

16

Aktivitas-aktivitas dalam analisa produk

1. Analisa sistemDilakukan dengan sasaran sebagai berikut: Mengidentifikasi kebutuhan pelanggan Mengevaluasi konsep sistem untuk feasibilitas Mengalokasikan fungsi-fungsi untuk perangkat keras, perangkat

lunak, manusia, database, dan elemen sistem yang lain Membuat batasan biaya dan jadwal Menciptakan definisi sistem yang membentuk pondasi bagi

semua kerja rekayasa subsekuen

2. Identifikasi Kebutuhan Dilakukan dengan cara melakukan pertemuan antara Analis

(perekayasa sistem) dengan pelanggan dan pemakai akhir Hasil dari indentifikasi kebutuhan dispesifikasi dalam suatu

dokumen konsep sistem

Page 17: RPL4 - System Engineering

17

Aktivitas-aktivitas dalam analisa produk3. Studi Feasibilitas

Feasibilitas ekonomi; evaluasi biaya pengembangan dibobot dengan pemasukan utama atau keuntungan yang didapat dari sistem atau produk yang dikembangkan

Feasibilitas teknis; studi mengenai fungsi, kinerja, dan batasan yang dapat mempengaruhi kemampuan untuk mencapai sebuah sistem yang baik

Feasibilitas legal; pertimbangan mengenai pelanggaran, kekerasan, atau liabilitas yang dihasilkan dari pengembangan sistem

Alternatif; evaluasi sebagai alternatif untuk mengembangkan sistem4. Analisis Ekonomi

Analisis biaya keuntungan yang menggambarkan biaya untuk pengembangan proyek dan membandingkannya dengan keuntungan yang nyata dan tidak nyata dari suatu sistem.

5. Analisis Teknis Analis mengevaluasi kebaikan teknis dari konsep sistem, dan pada

saat yang sama mengumpulkan informasi tambahan mengenai kinerja, reliabilitas, kemampuan pemeliharaan, dan produksibilitas.

Page 18: RPL4 - System Engineering

18

Pemodelan Arsitektur Sistem Untuk mengembangkan model sistem maka digunakan

template arsitektur, yang terdiri dari lima daerah pemrosesan: (1) interface pemakai; (2) input; (3) fungsi dan kontrol; (4) output; (5) pemeliharaan dan self-test.

Pemrosesan interface pemakai

Pemrosesaninput

Pemrosesanoutput

Fungsi proses dan kontrol

Pemeliharaan dan self-test

Page 19: RPL4 - System Engineering

19

Contoh: Diagram konteks arsitektur untuk CLSS

Sistem Pengurutan

Conveyor Line

OperatorStasiunsorting

OperatorStasiunsorting

PembacaBar code

Conveyorlain

Mekanismepengurutan

mainframe

permintaan Query danreport

Perintahlangsir

Bar code

Data diagnostik

Indikatorkecepatan

Data pelaporanterformat

Page 20: RPL4 - System Engineering

20

REQUIREMENT ENGINEERING

Page 21: RPL4 - System Engineering

21

Analisis Persyaratan

Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi perangkat lunak tingkat sistem dan perancangan perangkat lunak.

Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak.

Analisis persyaratan memberikan model-model yang akan diterjemahkan ke dalam data, arsitektur, interface, dan desain prosedural kepada perancang perangkat lunak.

Analisis persyaratan perangkat lunak dapat dibagi menjadi lima area kerja:1) Pengenalan masalah2) Evaluasi dan sintesis3) Pemodelan4) Spesifikasi5) kajian

AnalisisPersyaratanPerangkat

Lunak

Desain Perangkat

Lunak

RekayasaSistem

Page 22: RPL4 - System Engineering

22

Kasus

Pemasok besar suku cadang kendaraan bermotor membutuhkan sistem kontrol inventaris. Analis mendapatkan bahwa masalah yang berhubungan dengan sistem manual yang ada meliputi: Ketidakmampuan untuk dengan cepat memperoleh status suatu komponen Dua atau tiga hari berkali-kali memperbarui suatu file kartu Pemesanan kembali secara bertingkat kepada penjual yang sama karena

tidak ada cara untuk menghubungkan para penjual dengan komponen, dsb. Setelah mengevaluasi masalah yang ada dan juga informasi yang

diperlukan (input-output), analis mulai mensintesa satu atau lebih penyelesaian.

Untuk memulainya, data, fungsi-fungsi pemrosesan, dan tingkah laku sistem didefinisikan secara detail.

Proses evaluasi dan sintesis berlangsung sampai analis dan pelanggan yakin bahwa perangkat lunak dapat ditentukan untuk pengembangan sistem selanjutnya.

Page 23: RPL4 - System Engineering

23

Kasus

Dalam melakukan analisis, fokus utama analis adalah pada ‘apa’? bukan ‘bagaimana’.Data apakah yang diproduksi dan dikonsumsi, batasan apakah yang dipakai?

Selama aktivitas sintesis evaluasi dan solusi, analis menciptakan model-model sistem untuk memahami aliran data dan kontrol, operasi behavioral dan pemrosesan fungsional, serta muatan informasi.

Model tersebut berfungsi sebagai fondasi bagi desain perangkat lunak dan sebagai dasar untuk membuat spesifikasi perangkat lunak.

Spesifikasi lengkap belum bisa didapatkan pada tahap ini, pendekatan alternatif pada analisis persyaratan adalah prototyping

Page 24: RPL4 - System Engineering

24

Teknik Komunikasi Proses awal

Mengadakan pertemuan pendahuluan atau wawancara antara analis dengan pelanggan.

Rangkaian pertanyaan berfokus pada pemahaman yang mendasar atas masalah, orang yang menginginkan penyelesaian, sifat penyelesaian yang diinginkan, dan efektivitas pertemuan itu sendiri.

Teknik spesifikasi aplikasi yang terfasilitasi (facilitated aplication specification techniques = FAST) pertemuan dilakukan ditempat netral yang dihadiri oleh

pengembang maupun pelanggan Aturan main untuk persiapan telah dibuat Ada fasilitator yang bertugas mengontrol pertemuan

Penyebaran fungsi kualitas Quality function Deployment (QFD) adalah teknik manajemen

kualitas yang menterjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak

QFD berkonsentrasi pada pemaksimalan kepuasan pelanggan

Page 25: RPL4 - System Engineering

25

Prinsip-Prinsip Analisis

Prinsip Operasional Domain informasi dari suatu masalah harus dipahami Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus

didefinisikan Tingkah laku perangkat lunak harus direpresentasikan Model-model yang menggambarkan informasi, fungsi dan tingkah

laku harus dipecah-pecah secara hirarki Proses analisis harus bergerak dari informasi dasar ke detail

implementasi Prinsip Panduan untuk rekayasa persyaratan

Memahami masalah sebelum membuat model analisis Mengembangkan prototipe, sehingga pemakai memahami bagaimana

interaksi manusia dan komputer Merekam asal dan alasan untuk setiap persyaratan Menggunakan pandangan persyaratan bertingkat Memprioritaskan persyaratan Mengurangi ambiguitas