Tugas Rekayasa Perangkat Lunak

Tugas Rekayasa Perangkat Lunak Disusun Oleh : M Ikhsan Ariya Girinata 41813120052 Dosen : Wachyu Hari Haji, S.Kom, MM FAKULTAS ILMU KOMPUTER JURUSAN SISTEM INFORMASI Mata Kuliah : REKAYASA PERANGKAT LUNAK Jakarta 2015

Spesifikasi Perangkat Lunak : Teknik kebutuhan perangkat lunak (requirements engineering) atau sering juga disebut analisis kebutuhan perangkat lunak (Bahasa Inggris: requirements analysis) mencakup kegiatan dalam menentukan kebutuhan-kebutuhan atau kondisi yang harus dipenuhi untuk suatu produk baru atau yang akan diganti, dengan mempertimbangkan kemungkinan terjadinya konflik kebutuhan dari berbagai macam stakeholder. Analisis kebutuhan mempunyai peran penting dalam kesuksesan suatu proyek perangkat lunak. Kebutuhan harus terdokumentasi, dapat ditindaklanjuti (actionable), dapat diukur (measureable), dapat diuji, memiliki kaitan dengan kebutuhan dan peluang bisnis, serta memiliki tingkat kerincian yang cukup untuk perancangan sistem. Kebutuhan perangkat lunak dapat berupa kebutuhan fungsional dan non-fungsional. Kebutuhan Perangkat Lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai. Jenis perangkat lunak : 1. Kebutuhan fungsional : kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak. contoh : perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan 2. Kebutuhan Antarmuka : kebutuhan yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data. contoh : perangkat untuk input data dapat berupa keyboard, mouse, dan scanner. 3. Kebutuhan unjuk kerja : kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak contoh : perangkat lunak harus bisa mengolah data sampai 1juta record untuk tiap transaksi

Diagram Aliran Data/Data Flow Diagram : Diagram untuk menggambarkan aliaran data dalam sistem, sumber dan tujuan data, proses yang mengolah data tersebut dan tempat penyimpanan data. Aturan Pembuatan Diagram Aliran Data: 1. Setiap proses wajib memiliki data masukan dan data keluaran, selain itu TERLARANG. 2. Nama proses wajib menggunakan kata kerja 3. Data store tidak boleh mengalir langsung dari/ke data store lain, harus melalui proses dulu. 4. Data store tidak boleh mengalir langsung ke tujuan data/entitas, harus melalui proses dulu (idem dengan yang diatas) 5. Nama data store harus menggunakan kata benda 6. Entitas tidak boleh mengalir dari sumber data ke tujuan data, harus melalui proses (serba lewat proses deh pokoknya) 7. Nama entitas harus menggunakan kata benda 8. Aliran data hanya boleh memiliki satu arah aliran, aliran dua arah hanya boleh dimiliki antara proses dengan data store yang menunjukkan pembacaan dan peng-update-an data. 9. Aliran data yang sama yang menuju beberapa proses, data store atau entitas data yang berbeda, boleh digambarkan bercabang 10. Aliran data yang sama yang dari beberapa proses, data store atau entitass data yang menuju satu proses tertentu boleh digambarkan bercabang. 11. Aliran data tidak boleh mengalir ke dirinya sendiri 12. Nama aliran data menggunakan kata benda. Kamus data : merupakan suatu tempat penyimpanan (gudang) dari data dan informasi yang dibutuhkan oleh suatu sistem informasi. kamus data digunakan untuk mendeskripsikan rincian aliran data atau informasi yang mengalir dalam sistem, elemen data, file maupun basis data dalam DFD. Spesifikasi Proses : merupakan metode yang digunakan untuk menggambarkan deskripsi dan spesifikasi dari setiap proses yang paling rendah yang ada pada sistem.

Permasalahan Dalam Rekayasa Perangkat Lunak Stakeholder sering tidak mengetahui apa yang diinginkan dan mengungkapkan keinginannya dalam kalimat yang umum. Stakeholder mengungkapkan permintaan dalam istilah bidang pekerjannya, sehingga perekayasa kebutuhan yang tidak memiliki pengalaman bidang kerja pemesan harus memahami permintaan tersebut. Beberapa stakeholder memilki permintaan yang berbeda-beda yang dinyatakan dalam cara yang berbeda pula. Faktor politik dapat mempengaruhi kebutuhan system. Lingkungan bisnis dan ekonomi bersifat dinamis. Permasalahan dalam Rekayasa Kebutuhan Perangkat Lunak Inilah permasalahan yang sering terjadi, adalah banyak cara dalam hal menemaninya.

Tipe Kebutuhan : Kebutuhan dapat dibedakan menjadi : Kebutuhan fungsional, yang mendiskripsikan layanan-layanan atau fungsi-fungsi dari system. Kebutuhan non-fungsional, yang merupakan batasan-batasan pada system atau pada proses pengembangan sisyem. Berikut ini adalah tingakatan dalam kebutuhan : Spesifikasi perangkat lunak, ditujukan untuk menetapkan layanan apa yang dituntut dari sistem dan batasan pada-operasi dan pengembangan sistem. Kegiatan ini sering disebut rekayasa persyaratan. Rekayasa persyaratan merupakan tahap yang sangat kritis dari proses perangkat lunak karena kesalahan pada tahap ini pada akhirnya menimbulkan masalah lain pada perancangan dan implementasi sistem.

Sebuah dokumen yg berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak,tanpa menjelaskn bagaimana hal tersebut dikerjakan oleh perangkat lunak. Suatu SRS harus mencantumkan tentang deskripsi dgn lingkungannya. Mencakup antar muka untuk perangkat keras,perangkat lunak,komunikasi dan pemakai. SRS bisa terdiri dari banyak doku mentasi yang saling melengkapi. Suatu SRS harus dapat : 1. Menguraikan definisi masalah 2. Menguraikan masalah dengan tepat dengan cara tepat pula. Objektif SRS : 1. Persetujuan kerja dengan pelanggan 2. Daftar kebutuhan teknis yang harus dipenuhi perangkat lunak. Syarat pembentukan SRS : 1. Mudah diidentifikasi 2. Diuraikan dengan jelas,simple, sederhana dan concise (jelas,tidak ambiguous) 3. Bisa divalidasi dan bisa ditest. 4. Mampu untuk ditelusuri kembali. Hindari hal-hal berikut saat pembentukn SRS : 1. Over spesification (penjelasan berlebih dan berulang-ulang sehinga tidak jelas. 2. Tindakan unconcistency. 3. Ambiguity dalam kata atau kalimat 4. Menuliskan hal yang tidak bisa dilakukan. Dalam suatu SRS ada 2 aspek yang harus dilihat : 1. Fungsi Menjelaskan fungsi dari perangkat lunak(digunakan untuk apa keperluan apa),sifat dan datanya.

2. Non Fungsi Dependability a) Reliability b) Maintability c) c. Seccurity d) d. Integrity Ergonomic Performance Constraint. Atribut suatu SRS 1. Benar (correct) Spesifikasi yang ditulis benar. 2. Tepat (precise) Berpengaruh terhadap hasil perancangan dan pembuatan Software Requirement Design. 3. Unambiguouity Setiap permintaan harus punya satu interpretasi atau hanya satu arti dalam satu kalimat. 4. Lengkap Jika dilihat dari 2 sudut pandang : a) Dokumen membuat Tabel Isi,nomor halaman,nomor gambar,nomor tabel. b) Tidak ada bagian yang hilang (to be define) dari tulisan. 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 spesifik. 7. Understandable Dapat dimengerti oleh pemogram,analis sistem atau sistem engineer. 8. Bisa Dimodifikasi (Modifieable) 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 What). 11. Dapat mencakup dan melingkupi seluruh sistem. 12. Dapat melingkupi semua lingkungan operasional.

13. Bisa menggambarkan sistem seperti yang dilihat pemakai. 14. Harus dilokalisasi dengan coupling yaitu hubungan ketergantungan antara dua modul. Orang yang terlibat dalam SRS 1. Pemakai (User) Yang mengoperasikan /menggunakan produk final dari perangkat lunak yang dibuat. 2. Client Orang atau perusahaan yang mau membuat sistem (Yang menentukan). 3. Sistem Analis(Sistem Engineer) Yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan,menerima dan menulis requirement. 4. Software Engineer Yang bekerja setelah kebutuhan perangkat lunak dibuat. 5. Programmer Menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa modul. 6. Test Integration Group Kumpulan orang yang melakukan test dan mengintegrasi modul. 7. Maintenance Group Memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul. 8. Technical Support Orang-orang yang mengelola pengembangan PL. 9. Staff & Clerical Work Bertugas mengetik, memasukkan data dan membuat dokumen. Keberhasilan Pengembangan Perangkat Lunak 1. Ketelitian dari pembuatnya. 2. Kualitas dan spesifikasi perangkat lunak yang dihasilkan. 3. Integritas 4. Proses pembuatan yang mantap. 5. Mudah dikembangkan.

6. Jumlah versi yang tidak banyak. 7. Ketelitian dari model pengembangan yang digunakan untuk meramal atribut perangkat lunak. 8. Efektivitas rencana test dan integrasi. 9. Tingkat persiapan untuk sistem perawatan (mempersiapkan pencarian bugs). Fase-fase Spesifikasi Perangkat Lunak Studi kelayakan. Dibuat perkiraan mengenai apakah user yang diidentifikasi puas menggunakan perangkat lunak dan teknologi perangkat keras yang dipakai pada saat ini. Studi kelayakan seharusnya murah dan cepat. Hasilnya harus menginformasikan keputusan apakah kita akan terus dengan analisis yang lebih rinci, atau tidak Validasi persyaratan. Kegiatan ini memeriksa apakah persyaratan dapat direalisasikan, konsisten, dan lengkap. Elisitasi dan analisis persyaratan. Ini merupakan proses penurunan persyaratan sistem melalui observasi sistem yang ada, diskusi dengan user yang akan memakai dan yang mengadakan, analisis pekerjaan, dll. Spesifikasi persyaratan. Spesifikasi persyaratan adalah kegiatan menerjemahkan informasi yang dikumpulkan pada kegiatan analisis menjadi dokumen yang mendefinisikan serangkaian persyaratan. Proses Rekayasa Persyaratan

Perancangan & Implementasi Perangkat Lunak Tahap implementasi pengembangan perangkat lunak merupakan proses pengubahan spesifikasi sistem menjadi sistem yang dapat dijalankan. Tahap ini selalu mencakup proses perancangan dan pemrograman perangkat lunak. Perancangan perangkat lunak merupakan deskripsi struktur perangkat lunak yang akan diimplementasikan, data yang merupakan bagian sistem, interface antara komponen-komponen sistem dan, kadang-kadang, algoritma yang digunakan. Tahap proses perancangan bersifat urut (sekuensial). Pada kenyataannya, kegiatan proses perancangan akan saling tumpang tindih. Spesifikasi untuk tahap berikutnya merupakan output dari setiap kegiatan perancangan. Spesifikasi ini bisa merupakan spesifikasi abstrak dan formal yang dihasilkan untuk menjelaskan persyaratan, tapi bisa juga merupakan spesifikasi mengenai bagaimana bagian sistem akan direalisasikan. Kegiatan Proses Perancangan Spesifik

Perancangan arsitektural. Subsistem-subsistem yang membentuk sistem dan hubungan mereka diidentifikasi dan didokumentasi. Spesifikasi abstrak. Untuk setiap subsistem, spesifikasi abstrak dari layanan dan batas operasinya harus ditentukan. Perancangan interface. Untuk setiap subsistem, interface dengan subsistem dirancang dan didokumentasi. Perancangan komponen. Layanan dialokasikan pada komponen yang berbeda dan interface komponen-komponen ini dirancang. Perancangan struktur data. Struktur data yang dipakai pada implementasi sistem dirancang secara rinci dan dispesifikasi. Perancangan algoritma. Algoritma yang digunakan untuk memberikan layanan dirancang secara rinci dan dispesifikasi. Metode Perancangan Metodis terhadap perancangan perangkat lunak adalah metode terstruktur' yang merupakan serangkaian notasi dan panduan untuk perancangan perangkat lunak. Metode terstruktur mencakup model proses perancangan, notasi untuk merepresentasikan desain tersebut, format laporan, aturan dan panduan perancangan. Walaupun ada banyak metode, mereka memiliki banyak kesamaan. Metode System Model aliran data, di mana sistem dimodelkan dengan menggunakan transformasi data yang terjadi pada saat pemrosesannya. Model relasi entitas merupakan teknik normal yang dipakai untuk mendeskripsikan struktur database. Model struktural, di mana komponen-komponen sistem dan interaksinya didokumentasikan.

Metode berorientasi objek mencakup model inheritansi (pewarisan) sistem, model hubungan statis dan dinamis di antara objek, dan model bagaimana objek berinteraksi saw sama lain ketika sistem sedang dijalankan. Pemrograman dan Debug Pemrograman merupakan kegiatan pribadi dan di sini tidak ada proses umum yang biasanya diikuti. Beberapa programer akan mulai dengan komponen-komponen yang mereka pahami, mengembangkannya dan kemudian berlanjut ke komponen-komponen yang kurang dimengerti. Programmer melakukan pengujian terhadap kode yang telah mereka kembangkan. Kegiatan ini disebut debugging. Pengujian error dan debug merupakan proses yang berbeda. Pengujian menentukan adanya error. Debug berhubungan dengan pencarian lokasi dan pembetulan error ini. Error pada kode harus dilokalisasi dan program dimodifikasi untuk memenuhi persyaratan. Pengujian kemudian harus diulang untuk menjamin bahwa perubahan telah dilakukan dengan benar. Dengan demikian, proses debug merupakan bagian dari pengembangan perangkat lunak dan pengujian perangkat lunak.

Daftar Pustaka : http://www.slideshare.net/sherlyuda/rekayasa-kebutuhan-perangkat-lunak http://www.slideshare.net/arfianti/spesifikasi-perangkat-lunak http://wsilfi.staff.gunadarma.ac.id/downloads/files/5171/kebutuhan+dan+spesifikasi+p L.pdf