Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

 Perencanaan sistem atau feasibility merupakan tahap paling awal sebelum melakukan pengembangan sistem informasi  Tahap ini digunakan untuk menentukan.

Presentasi serupa


Presentasi berjudul: " Perencanaan sistem atau feasibility merupakan tahap paling awal sebelum melakukan pengembangan sistem informasi  Tahap ini digunakan untuk menentukan."— Transcript presentasi:

1

2  Perencanaan sistem atau feasibility merupakan tahap paling awal sebelum melakukan pengembangan sistem informasi  Tahap ini digunakan untuk menentukan apakah pengembangan sistem informasi akan dilakukan atau tidak

3  mendefinisikan proyek,  memodelkan proyek,  membuat perkiraan anggaran dan  Membuat penjadwalan proyek,  menyeimbangkan rencana proyek  menyetujui rencana proyek

4  Perencanaan sistem merupakan suatu aktivitas yang harus dilaksanakan sebelum dikembangkannnya sebuah sistem.  Perencanaan sistem perlu dilakukan agar pembangunan/pengembangan sistem sesuai :  blueprint yang ada, yang sesuai dengan visi, misi, tujuan dan sasaran organisasi.

5  Pengambil keputusan pada suatu organisasi yaitu manajemen tingkat atas ( executive).  Namun, kadang-kadang manajemen akan meminta pendapat bawahannya, yaitu :  manajer level menengah (middle manager)  maupun calon pengguna aplikasi (functional user), dalam melakukan pengambilan keputusan pelaksanaan proyek

6  Executive (manajemen tingkat atas) Prioritas utama executive adalah ROI (Return On Invesment). Jadi agar proyek dapat disetujui, maka anda harus mampu meyakinkan mereka bahwa proyek tersebut dapat meningkatkan ROI  Middle manager (manajer level menengah) Prioritas utama middle manager biasanya adalah bagaimana meningkatkan produktivitas kerja. Jadi sistem informasi yang akan dikembangkan tersebut harus mampu menunjukkan seberapa besar produktivitas kerja akan meningkat dengan adanya sistem baru tersebut..

7  Functional user (pengguna aplikasi langsung) Kebutuhan utama functional user adalah suatu aplikasi yang akan mempermudah pekerjaan mereka. Jadi jika functional user dilibatkan dalam pengambilan keputusan, maka anda harus mampu menunjukkan kemudahan-kemudahan apa yang akan diperoleh functional user dengan adanya sistem informasi yang akan dikembangkan tersebut.

8  Sebuah dokumen proposal proyek tersebut minimal terdiri dari hal-hal sebagai berikut: 1. Keuntungan yang akan diperoleh calon pengguna dengan adanya sistem informasi yang akan dikembangkan tersebut. Anda sebaiknya mengetahui siapa yang mengambil keputusan pengadaan sistem baru dan tunjukkan kelebihan sistem baru tersebut sesuai dengan karakteristik kebutuhannya. 2. Rencana biaya yang dibutuhkan untuk pengembangan, jika anda menjual sistem informasi tersebut ke pihak lain, berarti rencana biaya pengembangan di sini diganti dengan harga sistem informasi yang anda jual. 3. Waktu yang dibutuhkan untuk pengembangan sistem.

9  menetapkan suatu kerangka kerja strategi menyeluruh untuk memenuhi kebutuhan informasi pemakai.  melibatkan manajer senior, pemakai senior dan profesional sistem.  memastikan bahwa proyek yang diusulkan dievaluasi dan diprioritaskan.  memenuhi alasan untuk melakukan perencanaan sistem yang digunakan untuk : 1. dihubungkan dengan rencana bisnis 2. menghindari sejumlah kerugian  membagi tugas dan tanggung jawab pada orang yang merencanakan sistem, misalnya : o Steering Committee (SC),

10  membuat komponen laporan, yg meliputi : 1. komponen keseluruhan berhubungan dengan sumber daya yg akan diperoleh (3-5 tahun), meliputi : personil baru, hardware, software, peralatan telekomunikasi, lokasi computer dan keamanan. 2. komponen aplikasi: suatu portfolio yang disetujui dari proposal proyek sistem, secara luas menyatakan apa saja yang termasuk dalam komponen keseluruhan.

11  melakukan komunikasi dengan analis sistem, yang meliputi : 1. keduanya berhubungan dengan proses mendefinisikan kebutuhan pemakai 2. perbedaannya pada cakupan dan tahap pada perencanaan pengembangan sistem  memastikan bahwa pada perencanaan sistem, suatu sistem yang diusulkan harus layak dan mendukung faktor strategik.  Untuk menilai kedua kemungkinan tersebut maka harus diadakan evaluasi terhadap faktor kelayakan dan faktor strategi.

12  Pemodelan proyek mempunyai fokus pada pembuatan simulasi mengenai usaha yang dibutuhkan untuk mencapai tujuan proyek  Pemodelan ini menghasilkan sebuah WBS ( Work Breakdown Structure)  WBS adalah daftar semua pekerjaan yang harus dilakukan untuk menghasilkan produk yang diinginkan  WBS ( Work Breakdown Structure) yang digunakan untuk menentukan semua usaha yang dibutuhkan untuk menyelesaikan proyek dengan sukses.  Sebuah metode yang efektif dalam pembuatan WBS adalah membuat sebuah sesi diskusi yang melibatkan semua anggota tim dan memberikan kesempatan bagi mereka untuk memberikan ide-ide yang mereka miliki

13  Langkah 1: Membuat estimasi pekerjaan i. Estimasi pekerjaan seharusnya melibatkan anggota tim yang menjalankan pekerjaan tersebut. ii. Sehingga estimasi tersebut akan realistis dan anggota tim akan punya komitmen dan termotivasi untuk mencapai estimasi tersebut. iii. Estimasi ini kemudian dapat dimodifikasi untuk menyesuaikan dengan jadwal dan sumber daya yang ada.

14  Langkah 2: Membuat perencanaan awal i. Perencanaan awal proyek berisi sebuah jadwal yang dibuat berdasarkan ketergantungan antar pekerjaan ( task) dan estimasi pekerjaan tersebut. ii. Jadwal tersebut berisi kapan pekerjaan dimulai, berapa lama, dan kapan pekerjaan tersebut harus sudah selesai. iii. Biaya dapat dihitung dari pekerjaan apa saja yang harus dilakukan dan biaya untuk pembelian barang untuk proses perencanaan sistem

15  Langkah 4 : Negosiasi perubahan untuk estimasi i. Anda melakukan perubahan estimasi mengenai rencana waktu dan anggaran agar sesuai dengan tujuan awal. ii. Langkah ini mengandung risiko sangat besar apabila anda melakukannya tanpa persetujuan anggota tim yang lain, maka anda akan kehilangan komitmen dan motivasi anggota tim. iii. Anggota tim akan beranggapan jadwal dan anggarannya tidak realistis, sehingga kemungkinan proyek gagal menjadi sangat besar.

16  Langkah 5 : Negosiasi perubahan untuk tujuan proyek i. Langkah ini adalah melakukan negosiasi dengan executive karena dengan perubahan estimasi yang telah anda lakukan, rencana awal tersebut tidak realistis. ii. Perubahan rencana tersebut dapat berupa penambahan waktu dan anggaran maupun pengurangan kompleksitas sistem. iii. Usahakan agar sebisa mungkin rencana yang anda lakukan telah disetujui oleh anda, anggota tim anda, dan executive

17  Langkah 6 : Membuat keputusan terus/berhenti Setelah melakukan langkah 4 dan 5, anda harus mengambil keputusan apakah akan meneruskan proyek tersebut maupun tidak.

18  Langkah 7 : Mempersiapkan jadwal dan anggaran Rencana awal pengembangan sistem informasi telah siap. Rencana ini terdiri dari tiga hal, yaitu : i. jadwal kegiatan (waktu mulai, durasi, dan waktu selesai), ii. alokasi sumber daya manusia terhadap kegiatan, dan iii. rencana anggaran.

19 analisis sistem adalah mendefinisikan kebutuhan terkait sistem yang akan dikembangkan Jadi hasil akhir dari tahap analisis di sini adalah sebuah dokumen yang menjelaskan mengenai spesifikasi persyaratan sistem informasi atau SRS ( System Requirement Specification)

20

21  Fase analisis sistem memberikan pemahaman tentang sistem yang sudah ada dan menemukan peluang untuk pengembangan sistem menjadi lebih baik serta memenuhi kebutuhan bisnis.  Karena itu fase ini menjadi acuan penting dalam proyek pengembangan sistem informasi.

22  analisis terstruktur = Analisis terstruktur fokus pada aliran data melalui proses-proses bisnis dan perangkat lunak. Dikenal pula dengan nama analisis process-centered. Para analis sistem menggambar serangkaian model proses yang disebut diagram aliran data ( data flow diagram) yang mengilustrasikan proses-proses yang ada dan/atau yang diusulkan dalam sebuah sistem.

23  teknik informasi ( information engineering) = Analisis dengan teknik informasi fokus pada struktur data tersimpan dalam sebuah sistem, karena itu disebut analisis data-centered. Model-model proses dalam teknik ini digambarkan dengan diagram aliran data yang disebut hubungan entitas ( entity relationship).  analisis berorientasi objek = Analisis berorientasi objek menghilangkan pemisahan antara data dan proses, sebaliknya data dan proses yang akan membaca dan memperbarui serta menghapus data itu akan diintegrasikan ke dalam konstruksi

24  Analisis sistem dikendalikan oleh kepedulian antara para pemilik sistem dan pengguna sistem  Para analis sistem berperan sebagai fasilitator antara pemilik dan pengguna sistem.

25 Penetapan ruang lingkup ( 1 ) Analisis masalah ( 2 ) Analisis kebutuhan ( 3 ) Desain logik ( 4 ) Analisis Keputusan ( 5 ) Dokumentasi

26  Mengidentifikasi Masalah Awal yang ada pada sistem saat ini, seperti : 1. seberapa tingkat visibilitas keakuratan analisis sistem 2. berapa keuntungan yang akan diperoleh dari pemecahan masalah, 3. berapa keuntungan yang akan diperoleh dari prioritas dan penetapan solusi untuk memecahkan masalah

27  Menegosiasikan ruang lingkup untuk proyek pengembangan sistem  Menilai kelayakan proyek ( memberi nilai lebih atau tidak )  Mengembangkan jadual dan anggaran awal  Mengkomunikasikan rencana proyek ( antara pengembang sistem dan pengguna sistem / stakeholder sistem )

28  Pada fase ini selalu ada, baik sistem saat ini atau yang sudah ada,  Pada fase ini menyediakan analisis dengan pemahaman, kesempatan atau perintah lebih dalam yang memicu proyek pengembangan sistem

29  Memahami bidang masalah. 1. Tim analis mencoba mempelajari sistem saat ini. 2. Pemilik dan pengguna sistem memiliki persepsi berbeda tentang sistem yang ada, sehingga studi yang dilakukan dengan baik dapat mengungkap kepentingan semua pihak.

30  Menganalisis masalah-masalah dan kesempatan-kesempatan. Meski sudah dilakukan di fase sebelumnya, tetapi masalah- masalah awal tersebut hanya gejala, bukan masalah yang dipahami oleh pengguna sistem, tiap masalah dianalisis penyebab dan akibatnya

31  Menganalisis proses-proses sistem. Dikenal juga sebagai desain ulang proses sistem. Tim analis akan memeriksa setiap proses sistem dengan lebih rinci untuk mengukur nilai yang akan ditambahkan atau dikurangi  Menentukan tujuan-tujuan perbaikan sistem. Tim analis menentukan kriteria di mana semua perbaikan pada sistem akan diukur dan mengidentifikasi batasan yang membatasi fleksibilitas ( keakuratan ) semua perbaikan tersebut. Kriteria sukses diukur dengan tujuan, dimana setiap tujuan mewakili usaha

32  Mengkomunikasikan penemuan-penemuan dan merekomendasikan ke pengguna sistem

33 Sistem yang baru akan selalu dievaluasi apakah memenuhi atau tidak memenuhi sasaran dan kebutuhan sistem, karena itu fase ini tidak dapat diabaikan.

34  Mengidentifikasi dan menyatakan kebutuhan / persyaratan bisnis. Tugas ini menerjemahkan sasaran- sasaran kedalam functional requirement. Functional requirement adalah deskripsi mengenai aktivitas dan layanan yang harus diberikan / disediakan oleh sistem.  Membuat prioritas persyaratan sistem. Tidak semua persyaratan dibuat sama, karena tingkatan kebutuhannya akan selalu berbeda, karena itu pemilik dan pengguna sistem harus membuat prioritas persyaratan

35  Memperbarui atau memperhalus rencana proyek. Ruang lingkup adalah sebuah target yang berubah. Setelah mengidentifikasi persyaratan sistem, kita harus mundur dan menetapkan kembali pemahaman kita mengenai ruang lingkup proyek dan memperbarui rencana proyek kita untuk melakukan penyesuaian.  Mengkomunikasikan pernyataan kebutuhan Komunikasi adalah sebuah tugas fase analisis persyaratan yang berlangsung terus – menerus. Kita harus mengkomunikasikan persyaratan dan prioritas kepada komunitas pengguna sistem ( stakeholder ) melalui fase ini

36 Pada fase ini kita menggambarkan berbagai model sistem untuk mendokumentasikan persyaratan untuk sistem baru dan sistem yang ditingkatkan.

37 Dengan adanya persyaratan pengembangan sistem, maka kita dapat menekankan bagaimana sistem baru dapat diimplementasikan dengan teknologi. Di fase ini kita mengenali kandidat solusi, menganalisa kandidat solusi dan merekomendasi sebuah sistem yang akan dirancang, dibangun dan diimplementasikan

38 KarakteristikKandidat 1Kandidat 2Kandidat 3Kandidat …. Perangkat lunak yang diperlukan untuk mendesain dan membangun kandidat solusi  MS Visual C ++  MS Access  MS Visual Basic 5.0,  System Architect 3.1,  Internet Explorer  MS Visual Basic 7.0,  System Architect 4.1,  Internet Explorer ……………… ……………… ……………… ……………… ……………… ……………… ……………….

39 By Hendro Joko Prasetyo, M.Kom

40  Bab ini menjelaskan mengenai kebutuhan, macam-macam kebutuhan dan tahapan membuat Dokumen Spesifikasi Kebutuhan Sistem (System Requirement Specification / SyRS).  Tujuan 1. Mahasiswa mengetahui definisi kebutuhan 2. Mahasiswa dapat menemukan kebutuhan- kebutuhan dalam suatu kasus 3. Mahasiswa dapat membuat dokumen SyRS

41  Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai tujuan. Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen formal lainnya  Dengan mengadopsi pengertian-pengertian di atas, dapat disimpulkan bahwa kebutuhan sistem adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh sistem untuk memenuhi apa yang disyaratkan atau diinginkan pemakai

42 1. Kebutuhan fungsional (functional requirement) Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh sistem. Sebagai contoh: a) Sistem harus dapat menyimpan semua rincian data pesanan pelanggan. b) Sistem harus dapat membuat laporan penjualan sesuai dengan periode waktu tertentu. c) Sistem harus mampu menyajikan informasi jalur pengiriman barang terpendek.

43 2) Kebutuhan antarmuka (interface requirement) Kebutuhan antarmuka yang menghubungkan sistem dengan elemen perangkat keras, sistem, atau basis data. Sebagai contoh: a) Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau scanner. b) Akses ke basisdata menggunakan ODBC (Open Database Connectivity).

44 3) Kebutuhan unjuk kerja (performance requirement) Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh sistem, misalnya: kecepatan, ketepatan, frekuensi. Sebagai contoh: a) Sistem harus bisa mengolah data sampai 1 juta record untuk tiap transaksi. b) Sistem harus dapat digunakan oleh multiuser sesuai dengan otoritas yang diberikan pada user. c) Waktu tanggap penyajian informasi maksimal selama satu menit

45  Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat mempengaruhi sukses atau gagalnya pelaksanaan pengembangan sistem.  Menurut hasil survey DeMarco, 56% kegagalan proyek pengembangan sistem dikarenakan ketidaklengkapan pendefinisian kebutuhan dari sistem tersebut.  Produk sistem yang tidak sempurna akan dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan sangat mahal.

46  Analisis kebutuhan sistem (system requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan sistem  Analisis kebutuhan dilaksanakan setelah tahap rekayasa sistem/informasi dan software project planning.  Analisis kebutuhan dapat diartikan sebagai proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau sistem

47  Pelaksanaan pekerjaan analisis kebutuhan sistem antara lain adalah mempelajari dan memahami persoalan.  Pada tahap ini, seorang analis mempelajari masalah yang ada pada sistem yang dikembangkan, sehingga dapat ditentukan seperti : 1) siapa pemakai yang menggunakan sistem. 2) dimana sistem akan digunakan. 3) pekerjaan apa saja dari pemakai yang akan dibantu oleh sistem. 4) apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya. 5) apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari sisi hukum dan standar.

48 1) wawancara dengan pemakai 2) observasi atau pengamatan lapangan 3) kuesioner 4) mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisa dan perancangan sistem.

49 Pengumpulan data dengan menggunakan wawancara mempunyai beberapa keuntungan sebagai berikut:  Lebih mudah dalam menggali bagian sistem mana yang dianggap baik dan bagian mana yang dianggap kurang baik  Jika ada bagian tertentu yang menurut anda perlu untuk digali lebih dalam, anda dapat langsung menanyakan kepada narasumber  Dapat menggali kebutuhan user secara lebih bebas  User dapat mengungkapkan kebutuhannya secara lebih bebas.

50  Wawancara akan sulit dilakukan jika narasumber kurang dapat mengungkapkan kebutuhannya  Pertanyaan dapat menjadi tidak terarah, terlalu fokus pada hal-hal tertentu dan mengabaikan bagian lainnya.

51  Buatlah jadwal wawancara dengan narasumber dan beritahukan maksud dan tujuan wawancara  Gunakan pertanyaan yang jelas dan mudah dipahami. Hindari pertanyaan yang panjang dan kompleks  Cobalah untuk menggali mengenai kelebihan dan kekurangan sistem yang telah berjalan sebelumnya.

52  Anda boleh berimprovisasi dengan mencoba menggali bagian-bagian tertentu yang menurut anda penting, misalnya : melewati pertanyaan-pertanyaan yang sudah dijawab di pertanyaan sebelumnya, atau dapat dihapus jika dianggap tidak relevan berdasarkan informasi yang sudah diketahui secara pasti selama wawancara  Catat hasil wawancara tersebut.

53  Wawancara umumnya terdiri dari tiga fase yaitu pembukaan, isi dan kesimpulan.  Pembukaan bertujuan mempengaruhi atau memotivasi orang yang diwawancarai (narasumber) untuk berpartisipasi dan berkomunikasi dengan membangun lingkungan/suasana yang ideal.  Isi adalah fase dimana pewawancara memberikan pertanyaan kemudian mendengarkan/mengamati dengan baik jawaban verbal maupun nonverbal dari partisipan.  Kesimpulan merupakan tahap akhir dimana pewawancara menunjukkan penghargaan dan menyampaikan kesimpulan dari hasil wawancara

54 Yang Harus DilakukanYang Harus Dihindari  Bersikap sopan  Jadilah pendengar yang baik  Terkendali  Menyelidiki  Amati perangainya dan komunikasi nonverbalnya  Sabar  Menjaga sikap formal tapi santai  Melontarkan pertanyaan yang tidak perlu  Lebih banyak berbicara dibanding mendengarkan  Menggunakan kata-kata jargon dan kasar  Berdebat dengan partisipan  Mengkritik dan menyindir partisipan

55 Pengumpulan data dengan menggunakan observasi mempunyai keuntungan yaitu :  Analis dapat melihat langsung bagaimana sistem lama berjalan  Mampu menghasilkan gambaran lebih baik jika dibanding dengan teknik lainnya.

56  Membutuhkan waktu cukup lama karena jika observasi waktunya sangat terbatas maka gambaran sistem secara keseluruhan akan sulit untuk diperoleh  Orang-orang yang sedang diamati biasanya perilakunya akan berbeda dengan perilaku sehari- hari (cenderung berusaha terlihat baik). Hal ini akan menyebabkan gambaran yang diperoleh selama observasi akan berbeda dengan perilaku sehari-hari  Dapat mengganggu pekerjaan orang-orang pada bagian yang sedang diamati

57  Tentukan hal-hal apa saja yang akan diobservasi agar kegiatan observasi menghasilkan sesuai dengan yang diharapkan  Mintalah ijin kepada orang yang berwenang pada bagian yang akan diobservasi  Berusaha sesedikit mungkin agar tidak menganggu pekerjaan orang lain  Jika ada yang anda tidak mengerti, cobalah bertanya. Jangan membuat asumsi sendiri.

58  Hasilnya lebih objektif, karena kuisioner dapat dilakukan kepada banyak orang sekaligus  Waktunya lebih singkat.

59  Responden cenderung malas untuk mengisi kuisioner  Sulit untuk membuat pertanyaan yang singkat, jelas, dan mudah dipahami.

60  Hindari pertanyaan isian, karena responden biasanya malas untuk menulis banyak, dan jika responden menuliskan sesuatu sering kali susah untuk dipahami. Contoh pertanyaan yang memudahkan responden adalah pilihan ganda. Pertanyaan pilihan ganda memudahkan anda untuk melakukan rekapitulasi data hasil kuisoner  Buatlah pertanyaan yang tidak terlalu banyak  Buatlah pertanyaan yang singkat, padat, dan jelas.

61  Spesifikasi Kebutuhan Sistem (SRS) adalah sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh sistem, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh sistem.  SyRS bisa terdiri dari banyak dokumentasi yang saling melengkapi. Suatu SyRS harus dapat menguraikan definisi masalah, dan menguraikan masalah dengan tepat dengan cara yang tepat pula.

62  Pertama, SyRS dapat ditulis oleh pemakai potensial (pelanggan) dari sistem  kedua oleh pengembang sistem.

63  Untuk kasus pertama, tujuan penulisan SyRS adalah untuk mendefinisikan keinginan yang biasanya dinyatakan dalam bentuk penjelasan umum.  Untuk yang kedua, tujuan pembuatan SyRS adalah: - Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang sistem. - Dasar untuk merencanakan dan melaksanakan aktivitas pengujian sistem. - Acuan untuk melakukan perbaikan dan perubahan sistem.

64  Memastikan kesamaan antara kebutuhan untuk pengembangan dengan kebutuhan yang ditulis didalam dokumen.  Mendefinisikan kerangka kerja bersama untuk proses- proses pengembangan sistem.  Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam proses pengembangan sistem.  Memperjelas jenis dan isi dokumen.  Mengenali tugas, tahapan, baseline, aktivitas kaji ulang, dan dokumentasinya.  Belajar pendekatan praktis yang diterapkan didunia industri.  Menghilangkan persoalan-persoalan seperti yang pernah dialami masa lalu.

65  1) Mudah diidentifikasi  2) Diuraikan dengan jelas, simple, sederhana, dan concise (jelas, tidak ambiguous)  3) Bisa divalidasi dan bisa dites (test reliable, test accessable)  4) Mampu untuk ditelusuri kembali (tracebility)

66 1) Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas) 2) Tindakan unconcistency (seperti menggunakan istilah yang tidak konsisten) 3) Ambiguity dalam kata atau kalimat seperti menyatakan keterukuran kebutuhan secara tidak jelas misalkan menggunakan kata-kata :minimal, maksimal, optimal, cepat, user friendly, efisien, fleksible dan lainnya. 4) Menuliskan “mimpi-mimpi”, yaitu hal-hal yang tidak bisa dilakukan

67 1) Fungsi Menjelaskan fungsi dari sistem (digunakan untuk apa keperluan apa), sifat sistem, dan datanya. 2) Non-fungsi - Dependability - Ergonomic - Performance

68 1) Benar (correct) Suatu dokumen SyRS disebut benar jika dan hanya jika setiap kebutuhan yang dinyatakan dalam dokumen merepresentasikan sesuatu yang disyaratkan dari sistem yang akan diangun. 2) Tepat (precise) Berpengaruh pada hasil perancangan dan pembuatan software requirements design (SRD). 3) Unambiguouity Setiap permintaan harus punya satu intepretasi, atau hanya ada satu arti dalam satu kalimat.

69 4) Lengkap (complete) Lengkap jika dilihat dari dua sudut pandang: a) dokumen memuat tabel isi, nomor halaman, nomor gambar, nomor tabel, dan sebagainya. b) tidak ada bagian yang hilang (to be define) yaitu tulisan yang akan didefinisikan kemudian. 5) Bisa diverifikasi (verifiable) Bisa diperiksa dan dicek kebenarannya. Setiap kebutuhan selalu dimulai dengan dokumen yang bisa diperiksa. 6) Konsisten Nilai-nilai kebutuhan harus tetap sama baik dalam karakteristik maupun spesifikasi, misalnya diminta A tetap ditulis A.

70 7 ) Understandable Dapat dimengerti oleh pemrogram, analis sistem atau system engineer. 8) Bisa dimodifikasi (modifiedable) Bisa diubah-ubah dan pengubahannya sangat sederhana tetapi tetap konsisten dan lengkap. 9) Dapat ditelusuri (traceable) Jika ditelusuri, harus tahu mana bagian yang diubah. 10) Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menyelesaikan what tadi). 11) Dapat mencakup dan melingkupi seluruh sistem

71 12) Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional. 13) Bisa menggambarkan sistem seperti yang dilihat oleh pemakai. 14) Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan ketidakkonsistenan. 15) Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat

72 1) Pemakai (user) Kelompok orang yang mengoperasikan/menggunakan produk final dari sistem yang dibuat. 2) Client Orang atau perusahaan yang mau membuat sistem (yang menentukan). 3) System analyst (system engineer) Kelompok orang yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement.

73 4) Software engineer Kelompok orang yang bekerja setelah kebutuhan sistem dibuat (bekerja sama dengan system engineer saat mendefinisikan kebutuhan sistem dam membuat deskripsi perancangannya). 5) Programmer Kelompok orang yang menerima spesifikasi perancangan sistem, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul. 6) Test integration group Kelompok orang yang melakukan tes dan mengintegrasi modul.

74 7) Maintenance group Kelompok orang yang memantau dan merawat performansi sistem sistem yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan). 8) Technical Support Orang-orang yang mengelola (manage) pengembang sistem, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi. 9) Staff dan Clerical Work Kelompok orang yang bertugas mengetik, memasukkan data, membuat dokumen.

75 1) Ketelitian dari pembuatnya 2) Kualitas dari spesifikasi sistem yang dihasilkan (baik, jika ada sedikit kesalahan) 3) Integritas 4) Ketelitian 5) Proses pembuatan yang mantap 6) Mudah dikembangkan 7) Jumlah versi tidak banyak 8) Ketelitian dari model pengembangan yang digunakan untuk meramal atribut sistem 9) Efektivitas rencana tes dan integrasi 10) Tingkat persiapan untuk sistem perawatan (mempersiapkan pencarian bugs)

76 1. PENDAHULUAN 1.1 Tujuan 1.2 Ruang Lingkup 1.3 Definisi 1.4 Referensi 1.5 Sistematika

77 2. DESKRIPSI UMUM 2.1 Perspektif 2.2 Kegunaan 2.3 Karakteristik Pengguna 2.4 Batasan-batasan 2.5 Asumsi dan Ketergantungan

78 3. SPESIFIKASI KEBUTUHAN 3.1 Kebutuhan Fungsional Pendahuluan Input Proses Output 3.2 Kebutuhan Antarmuka Eksternal Antarmuka Pengguna Antarmuka Perangkat Keras Antarmuka Perangkat Lunak Antarmuka Komunikasi

79 3.3 Kebutuhan Performansi 3.4 Kendala Disain Standard Compliance Perangkat Keras 3.5 Atribut Keamanan Sistem Pemeliharaan 3.6 Kebutuhan Lain Database Pengoperasian Penyesuaian Tempat

80 1. PENDAHULUAN 1.1. Tujuan Tujuan dari dikembangkannya sistem 1.2. Ruang Lingkup Ruang lingkup dari pengembangan sistem 1.3. Definisi Definisi definisi dari istilah yang diguankan dalam dokumen SyRS ini 1.4. Referensi Referensi yang digunakan dalam mengembangkan dokumen SyRS 1.5. Sistematika Sistematika penulisan Spesifikasi Kebutuhan Sistem

81 2. DESKRIPSI UMUM 2.1. Perspektif Deskripsi umum sistem 2.2. Kegunaan Kegunaan dari sistem yang dikembangkan 2.3. Karakteristik Pengguna Karakteristik dari target pengguna sistem 2.4. Batasan-batasan Batasan-batasan yang terdapat dalam sistem 2.5. Asumsi dan Ketergantungan Asumsi dan ketergantungan yang diperhitungkan dalam pengembangan sistem

82 3. SPESIFIKASI KEBUTUHAN 3.1. Kebutuhan Fungsional Kebutuhan fungsional dari sistem yang mencakup input, proses, dan output dari sistem Pendahuluan Input Proses Output

83 3.2. Kebutuhan Antarmuka Eksternal Kebutuhan antarmuka yang terdapat dalam sistem yang mencakup segala jenis antarmuka, baik itu antarmuka untuk interaksi dengan pengguna, dengan perangkat keras lainnya, dengan perangkat lunak, dan sebagainya Antarmuka Pengguna Antarmuka Perangkat Keras Antarmuka Perangkat Lunak Antarmuka Komunikasi

84 3.3. Kebutuhan Performansi Kebutuhan performansi dari sistem 3.4. Kendala Disain Kendala dalam melakukan disain sistem yang terkait dengan standard compliance dan juga kendala disain yang diakibatkan keterbatasan perangkat keras Standard Compliance Perangkat Keras

85 3.5. Atribut Atribut dari sistem yang mencakup aspek keamanan sistem dan juga aspek pemeliharaan Keamanan Sistem Pemeliharaan 3.6. Kebutuhan Lain Kebutuhan sistem yang terkait dengan kebutuhan penyimpanan data, pengoperasian, serta kebutuhan dalam penyesuaian tempat Database Pengoperasian Penyesuaian Tempat


Download ppt " Perencanaan sistem atau feasibility merupakan tahap paling awal sebelum melakukan pengembangan sistem informasi  Tahap ini digunakan untuk menentukan."

Presentasi serupa


Iklan oleh Google