Apa

Apa
Apa
Apa

itu Perangkat Lunak (PL)?

itu Program dan Prosedur?
itu Rekayasa Perangkat Lunak?
tujuan dari pembelajaran Rekayasa Perangkat Lunak?

Perangkat Lunak adalah seluruh perintah yang digunakan untuk memproses informasi.
Perangkat Lunak dapat berupa program atau prosedur.
Program adalah kumpulan perintah yang dimengerti oleh komputer, sedangkan Prosedur
adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi.
Rekayasa Perangkat Lunak adalah ilmu yang membahas semua aspek produksi Perangkat
Lunak, dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari
kebutuhan pengguna, desain, pengkodean, pengujian sampai pemeliharaan sistem setelah
digunakan.
Tujuan dari pembelajaran Rekayasa Perangkat Lunak adalah dimana kita bisa menekan Biaya
(baik pembuatan dan perawatan) seminim dan serendah mungkin dan memanfaatkan Waktu yang
diberikan secara efektif dan efisien sehingga menghasilkan Kinerja yang tinggi, andal
dan tepat waktu.

1. Apa itu Perangkat Lunak (PL)?

- Menurut Roger S. Pressman, Ph.D. dalam bukunya Software engineering : a
practitioner's approach (1997), perangkat lunak adalah instruksi (program komputer)
yang bila dieksekusi dapat menjalankan fungsi tertentu, struktur data yang dapat
membuat program memanipulasi informasi, dokumen yang menjelaskan program
- Sedangkan menurut IEEE (Institute of Electrical and Electronics Engineers),
perangakat lunak adalah program komputer, prosedur, aturan dan dokumentasi yang
berkaitan serta data, yang bertalian dengan operasi suatu sistem komputer
- Jadi secara umum Perangkat lunak adalah kumpulan program komputer dengan fungsi
tertentu
Apa itu Program dan Prosedur?
- Menurut Wikipedia, Program komputer atau sering kali disingkat sebagai program adalah
serangkaian instruksi yang ditulis untuk melakukan suatu fungsi spesifik pada
komputer.Komputer pada dasarnya membutuhkan keberadaan program agar bisa menjalankan
fungsinya sebagai komputer, biasanya hal ini dilakukan dengan cara mengeksekusi
serangkaian instruksi program tersebut pada prosesor. Sebuah program biasanya memiliki
suatu bentuk model pengeksekusian tertentu agar dapat secara langsung dieksekusi oleh
komputer. Program yang sama dalam format kode yang dapat dibaca oleh manusia disebut
sebagai kode sumber, bentuk program yang memungkinkan programmer menganalisis serta
melakukan penelaahan algoritma yang digunakan pada program tersebut. Kode sumber
tersebut pada akhirnya dikompilasi oleh utilitas bahasa pemrograman tertentu sehingga
membentuk sebuah program. bentuk alternatif lain model pengeksekusian sebuah program
adalah dengan menggunakan bantuan interpreter, kode sumber tersebut langsung dijalankan
oleh utilitas interpreter suatu bahasa pemrograman yang digunakan.
- Menurut Abdul Kadir dalam bukunya Algoritma & Pemrograman menggunakan C & C ++(2012),
program adalah kumpulan instruksi yang dgunakan untuk mengatur komputer agar melakukan
suatu tindakan tertentu. Tanpa program komputer sesungguhnya tidak dapat berbuat apa apa. Itulah sebabnya, sering dikatakan bahwa komputer mencakup tiga aspek penting,

berupa perangkat keras (hardware), perangkat lunak (software), yang dalam hal ini
berupa program dan perangkat akal (brainware) atau orang yang berperan terhadap operasi
komputer maupun pengembangan perangkat lunak. Dengan kata lain, program merupakan salah
satu bagian penting pada komputer, yang mengatur komputer agar melakukan tindakan yang
sesuai dengan yang dikehendaki oleh pembuatnya.
Jadi secara umum, program adalah Adalah suatu produk atau hasil dari proses
pemrograman. Untuk dapat membuat suatu program, maka kita memerlukan compiler (alat
untuk menuliskan script-script pemograman).
Menurut Roger S. Pressman (1997) Komponen metodologi pengembangan perangkat lunak dapat
dibagi dalam tiga unit, yaitu :Metode, Alat bantu (Tools), dan Prosedur,
Prosedur merupakan salah satu komponen metodologi pengembangan perangkat lunak yang
dipergunakan untuk mendefinisikan urut-urutan pekerjaan (daur) dari metode dan alat
bantu tersebut.
Rekayasa perangkat lunak Menurut Stephen R. Schach
Rekayasa perangkat lunak adalah sebuah disiplin dimana dalam menghasilkan perangkat
lunak bebas dari kesalahan dan dalam pengiriman anggaran tepat waktu serta memuaskan
keinginan pemakai.
Rekayasa perangkat lunak Menurut Fritz Bauer
Rekayasa perangkat lunak adalah penetapan dan penggunaan prinsip rekayasa dalam rangka
memperoleh perangkat lunak yang dapat dipercaya dan dapat bekerja secara efisien pada
mesin nyata.
Rekayasa perangkat lunak Menurut IEEE
Rekayasa perangkat lunak adalah sebuah studi pendekatan dan aplikasi secara
sistematis, disiplin pengembangan operasi dan pemeliharaan perangkat lunak yang
kesemuanya itu merupakan aplikasi rekayasa yang berkaitan dengan perangkat lunak.
Jadi dapat disimpulkan bahwa rekayasa perangkat lunak adalah disiplin ilmu yang
menangani perancangan, pembuatan dan pmeliharaan suatu perangkat lunak dengan memakai
sistem atau pinsip aturan tertentu yang sistematis untuk menghasilkan sebuah perangkat
lunak yang sesuai dengan kebutuhan nyata pemakai dengan tingkat fungsi dan efisiensi
yang maksimal.
4. Apa tujuan dari pembelajaran Rekayasa Perangkat Lunak?
Adapun tujuan dari rekayasa perangkat lunak antara lain:
1. Untuk membangun software yang benar dan benar sebuah software
2. Untuk membangun software yang tepat. Dalam arti menghasilkan perangkat lunak yang
kinerjanya tinggi, andal dan tepat waktu, dapat bekerja pada berbagai jenis platform
3. Dikelola dengan baik untuk pemeliharaan kebenarannya.
4. Memperoleh biaya produksi perangkat lunak yang rendah.
5. Menghasilkan perangkat lunak yang biaya perawatannya rendah
Jelaskan apa yang saudara ketahui tentang proses perangkat lunak!
Jelaskan metode pengembangan perangkat lunak dan apa kelebihan dan kekurangan dari
setiap metode/model
Proses dalam perangkat lunak meliputi:
o Spesifikasi mendefinisikan apa yang harus sistem lakukan;
o Desain dan implementasi mendefinisikan organisasi dari sistem dan implementasi
sistem;
o Validasi memeriksa apakah sudah sesuai dengan keinginan pengguna;
o Evolusi mengubah sistem sebagai tanggapan dari berubahnya kebutuhan pengguna.
Jelaskan apa yang saudara ketahui tentang proses perangkat lunak!
Proses perangkat lunak adalah beberapa kegiatan yang menghasilkan perangkat lunak yang
benar benar perangkat lunak dalam artian memenuhi kebutuhan pemakai sehingga ketika
perangkat lunak siap digunakan tidak ada masalah / kendala yang terjadi nantinya saat
pemakaian perangkat lunak oleh user itu sendiri, sebagian besar hal ini dilakukan juga
oleh perekayasa perangkat lunak.

Secara umum Ada 4 macam kegiatan/aktivitas pada proses perangkat lunak :

1. Spesifikasi Perangkat Lunak
Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan Perangkat Lunak
Perangkat lunak yang memenuhi spesifikasi harus diproduksi.
3. Validasi Perangkat Lunak
Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa
yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak
Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.
Menurut Roger S. Pressman (2002), Metodologi pengembangan perangkat lunak (atau disebut
juga model proses atau paradigma rekayasa perangkat lunak) adalah suatu strategi
pengembangan yang memadukan proses, metode, dan perangkat (tools) . Metode-metode
rekayasa perangkat lunak, memberikan teknik untuk membangun perangkat lunak. Berkaitan
dengan serangkaian tugas yang luas yang menyangkut analisis kebutuhan, konstruksi
program, desain, pengujian, dan pemeliharaan .
Metode-Metode Pengembangan Perangkat Lunak (Model Proses Pengembangan Perangkat Lunak)
terdiri dari sebagai berikut
1. Waterfall Model
2. Prototyping Model
3. RAD Model
4. Incremental Model
5. Spiral Model
1. Waterfall Model
Pada model Waterfall atau disebut
terapkan, yaitu:
*
*
*
*
*

model air terjun, ada beberapa fase yang harus kita

Analisis kebutuhan lalu pendefenisiannya

Perancangan Sistem dan Perangkat lunaknya
Implementasi dan unit testing
Integrasi dan pengujian sistem
Pengoperasian dan perawatan

Dimana sebuah proses akan kembali ke state sebelumnya agar tidak ada perubahan setelah
proses menuju state di bawahnya sebab sangat sulit.
Kelebihan Waterfall Model :
1.Mudah diterapkan dan diaplikasikan.
2.Sesuai apabila digunakan untuk perangkat lunak yang kebutuhannya jelas dan dapat
diperhitungkan di awal pembuatan, sehingga kesalahan dapat dihindari.
3.Memberikan template tentang cara menganalisis, desain, pengkodean, pengujian, dan
pemeliharaan.
Kekurangan Waterfall model :
1.Bersifat kaku sehingga sulit untuk diubah pada sistem perangkat lunaknya.
2.Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen
harus dilakukan pada tahap awal proses.
3.Karena dilalukan setahap demi setahap, maka memakan waktu yang lebih lama.
4.Pembuatan dilakukan oleh sekelompok team sehingga apabila berhenti di tengah jalan
akan membingungkan anggota yang lain.
5.Apabila salah satu team belum selesai, harus ditunggu team yang lain sehingga waktu
terbuang untuk menunggu team tersebut.
2. Prototyping model
Metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari
sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan
sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan,
ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.
Kelebihan Prototyping model :
1.Komunikasi antara pengembang dan pelanggan menjadi lebih baik.
2.Menghemat waktu pengembangan.

3.Pengembang dapat menentukan kebutuhan pelanggan sehingga dia dapat bekerja dengan
baik.
4.Pemakai mengetahui apa yang diharapkannya sehingga penerapan menjadi lebih mudah.
5.User dapat berpartisipasi aktif dalam pengembangan sistem.
6.Dapat menangkap syarat/keperluan secara nyata.
7.Dapat mendukung secara standalone.
Kekurangan Prototyping model :
1.Apabila data yang dikumpulkan hanya sebagian maka banyak kebutuhan yang tidak
ditampilkan.
2.Bentuk prototype banyak yang tidak sesuai.
3.Proses analisis dan perancangan sangat singkat.
4.Versi perbaikan dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang.
5.Mengesampingkan alternatif pemecahan masalah.
6.Bisanya kurang fleksible dalam mengahadapi perubahan.
7.Prototype yang dihasilkan tidak selamanya mudah dirubah
8.Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum
mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan
kemampuan pemeliharaan untuk jangja waktu lama.
9.Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma
dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai
tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem.
10.Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik
perancangan yang baik.
11.Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem
operasi yang tidak relevan dan algoritma yang tidak efisien.
12.Prototype yang di setujui oleh client harus dikembangkan oleh developer tanpa ada
data tambahan dari client dan software dari prototype harus memiliki fungsi yang
lengkap.
3. Model RAD
Rapid Aplication Model (RAD) adalah sebuah proses perkembangan perangkat lunak
sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini
merupakan sebuah adaptasi kecepatan tinggi dari model sekuensial linier dimana
perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen.
Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan
menciptakan sistem fungsional yang utuh dalam periode waktu yang sangat pendek (kirakira 60 sampai 90 hari).
Kelebihan Model RAD :
1.Cocok untuk proyek yang memerlukan waktu yang singkat
2.Lebih efektif dan pendekatan waterfall/sequential linear dalam menghasilakn sistem
yang memenuhi kebutuhan langsung dari pelanggan.
Kekurangan model RAD :
1.Butuh orang banyak untuk menyelesaikan sebuah proyek berskala besar.
2.Pengembang dan customer harus punya komitmen yang kuat untuk menyelesaikan sebuah
software.
3.RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang tinggi.
4.Jika sistem tidak dibangun dengan benar maka RAD akan bermasalah.
5.Jika ada peubahan di tengah-tengah pengerjaan maka harus membuat kontrak baru antara
pengembang dan customer.
4. Incremental Model
Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa perangkat lunak
perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses membangun berhenti
jika produk telah mencapai seluruh fungsi yang diharapkan.
Adapun beberapa tahapan yang ada pada model incremental dimana tahapan-tahapan tersebut
dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing,
dikirim ke pemakai untuk langsung dapat digunakan.
Kelebihan incremental model :
1.Dikerjakan secara urut dan sistematis.

2.Mencagah ketidaknyamanan perubahan system. Klien dibiasakan perlahan-lahan

menggunakan produknya bagian per bagian.
3.Pembuat perangkat lunak yang diperlukan hanya sedikit.
4.Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga kemudahan pemakaian
sistem yang paling di utamakan.
5.Tahap awal adalan dasar dari pembuatan tahap berikutnya
6.Resiko yang rendah pada pengembangan sistem
7.Mampu menyesuaikan perubahan kebutuhan customer.
8.Memaksimalkan pengembalian modal investasi konsumen.
Kekurangan incremental model :
1.Hanya akan berhasil jika tidak ada staffing untuk penerapan secara menyeluruh.
2.Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut.
3.Hanya cocok untuk proyek dengan skala kecil.
4.kemungkinan tiap bagian tidak dapat diintegrasikan.
5. Model Spiral
Model ini cukup baru ditemukan,yaitu tahun 1988 oleh Barry Boehm. Spiral adalah salah
satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model
prototyping dan digabungkan dengan aspek sistematis yang dikembangkan model waterfall.
Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task
regions. Kebanyakan aktivitas2 tersebut dibagi antara 3 sampai 6 aktivitas. Berikut
adalah aktivitas-aktivitas yang dilakukan dalam spiral model :
* Customer communication.Aktivitas yang dibutuhkan untuk membangun komunikasi yang
efektif antara developer dengan user / customer terutama mengenai kebutuhan dari
customer.
* Planning.Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan
waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
* Analysis risk.Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko
secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada
model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral
model.
* Engineering.Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari
aplikasi secara teknikal.
* Construction & Release.Aktivitas yang dibutuhkan untuk develop software, testing,
instalasi dan penyediaan user / costumer support seperti training penggunaan software
serta dokumentasi seperti buku manual penggunaan software.
* Customer evaluation.Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user /
customer berdasarkan evaluasi mereka selama representasi software pada tahap
engineering maupun pada implementasi selama instalasi software pada tahap construction
and release.
Kelebihan model Spiral :
1.Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
2.Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko
sebelum menjadi permaslahan yang serius
3.Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak
komputer.
4.Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap
tingkat evolusi karena perangkat lunak terus bekerja selama proses.
5.Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di
dalam evolusi produk.
Kekurangan model Spiral :
1.Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan
developer.
2.Butuh waktu lama untuk menerapkan metode ini.
3.Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya
sukses.
4.Metode ini belum terjamin efisien.
5.Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius
jika resiko mayor tidak ditemukan dan diatur.

coba saudara diskusikan mengenai:

Rekayasa persyaratan
Persyaratan fungsional dan Non-fungsional
Dokumentasi Persyaratan Perangkat Lunak
Spesifikasi persyaratan user
Sebenarnya hampir semua Anda sudah benar, namun perlu saya tambahkan disini tentang
hubungan antara User Requirement dengan System Requirement atau sering disebut
Functional Requirement. Dari sisi pengguna (User) dimana Requirement bisa diartikan
sebagai kebutuhan, sedangkan dari sisi pembangun atau pengembang PL (Developer) maka
Requirement bisa diartikan sebagai Persyaratan. Oleh karena itu system requirement
merupakan jawaban (response) dari user requirement. Setiap user requirement bisa
memberikan response sebanyak satu atau lebih system requirement (functional
requirement). Sebagai contoh dalam sistem informasi perpustakaan dapat menghasilkan
user dan system requirement sbb:
User Requirement:
1. Pengguna perpustakaan dapat mencari suatu koleksi buku.
2. Staf bagian pengadaan dapat mengumpulkan informasi tentang buku yang akan dibeli.
3. dll
Response dari masing-masing user requirement tersebut di atas menghasilkan system
(functional) requirement sbb:
1.1. Sistem dapat menemukan (searching) koleksi buku melalui Judul Buku.
1.2. Sistem dapat menemukan koleksi buku melalui Pengarang Buku.
1.3. Sistem dapat menemukan koleksi buku melalui Penerbit Buku.
1.4. Sistem dapat menemukan koleksi buku melalui Tahun Terbit.
1.5. Sistem dapat menemukan koleksi buku melalui kombinasi tersebut di atas menngunakan
operator OR, AND, XOR (Advanced Searching).
2.1. Sistem memberikan kemudahan pemasukan usulan buku yang akan dibeli melalui Form
Imputan.
2.2. Sistem memberikan kemudahan menampilkan daftar usulan pengguna perputakaan yang
diurutkan.
Rekayasa persyaratan
Ada empat kegiatan proses rekayasa persyaratan tingkat tinggi yang generik adalah :
1. Studi kelayakan sistem
Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai dengan studi
kelayakan. Input bagi studi kelayakan adalah deskripsi garis besar sistem dan bagaimana
sistem akan digunakan dalam organisasi.
2. Elisitasi dan analisis persyaratan
Setelah studi kelayakan awal, tahap berikutnya dari proses rekayasa persyaratan
adalah elisitasi dan analisis persyaratan.
Pada tahap ini, staf pengembangan perangkat lunak teknis bekerja dengan pelanggan dan
end-user sistem untuk mencari domain aplikasi, layanan apa yang harus diberikan sistem,
kinerja sistem yang diharapkan, batasan perangkat keras, dan seterusnya.
3. Validasi persyaratan
Setelah studi kelayakan awal, tahap berikutnya dari proses rekayasa persyaratan
adalah elisitasi dan analisis persyaratan.
Pada tahap ini, staf pengembangan perangkat lunak teknis bekerja dengan pelanggan dan
end-user sistem untuk mencari domain aplikasi, layanan apa yang harus diberikan sistem,
kinerja sistem yang diharapkan, batasan perangkat keras, dan seterusnya.
4. Manajemen persyaratan
Manajemen persyaratan adalah proses pemahaman dan pengendalian perubahan pada
persyaratan sistem.
Proses manajemen persyaratan dilakukan bersama dengan proses rekayasa persyaratan yang
lainnya.
Perencanaan dimulai pada saat yang sama dengan elisitasi persyaratan awal dan manajemen
persyaratan aktif harus dimulai segera setelah versi draft dokumen persyaratan
tersedia.
Tipe tipe persyaratan antara lain

sebagai berikut :

- Persyaratan User
Laporan dalam bahasa natural plus diagram layanan yang tersedia dan batasan
operasional. Ditulis oleh konsumen.
- Persyaratan Sistem
Dokumen terstruktur yang berisi deskripsi detail dari fungsi sistem, layanan dan
batasan
operasional. Mendefinisikan apa yang harus dilaksanakan sehingga dapat menjadi bagian
dari kontrak antara konsumen dan developer.
Persyaratan Fungsional dan Non Fungsional
Persyaratan Fungsional adalah Pernyataan layanan tentang bagaimana sistem harus
bereaksi terhadap input, sistem harus berlaku pada situasi-situasi tertentu.
Secara khusus menyatakan apa yang tidak boleh dilakukan sistem. Merupakan
penjelasan tentang layanan yang perlu disediakan oleh system, bagaimana system menerima
dan mengolah masukan, dan bagaimana system mengatasi situasi situasi tertentu.
Selain itu kadang kadang juga secara jelas menentukan apa yang tidak
dikerjakan oleh system. Functional Requirement menggambarkan system requirement
secara detail seperti input, output dan pengecualian yang berlaku
Contoh Persyaratan fungsional:
* User dapat mencari semua atau satu set awal database atau memilih subset darinya.
* System akan menyediakan viewer yang sesuai bagi user untuk membaca dokumen pada
penyimpanan (store) dokumen.
* Semua pemesanan diberi identifier yang unik (ORDER_ID) yang dapat di copy user ke
area penyimpanan permanent untuk account tersebut.
Persyaratan Fungsional dan Non Fungsional
Persyaratan Non Fungsional adalah pernyataan tentang batasan layanan dan fungsi yang
diberikan sistem. Karena berkaitan dengan kebutuhan system secara keseluruhan, maka
kegagalan memenuhi kebutuhan jenis ini berakibat pada system secara keseluruhan.Contoh
kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas
penyimpanan yang diperlukan, privasi masing masing profil/account, bahasa
pemrograman yang digunakan, system operasi yang digunakan.
Persyaratan non-fungsional terdiri dari:
* Persyaratan Produk: persyaratan yang diambil dari spesifikasi produk, seperti
persyaratan hardware untuk mendukung kinerja.
* Persyaratan Organisasi: persyaratan yang berasal dari kebijakan dan prosedur pada
organisasi.
* Persyaratan Eksternal: persyaratan yang berasal dari factor eksteral terhadap system
dan proses pengembangannya.
Ukuran persyaratan non-fungsional
* Kecepatan: transaksi yang diproses perdetik, waktu tanggal user per event atau waktu
refres layar.
* Ukuran: KB atau jumlah Chip RAM.
* Kemudahan Penggunaan: waktu pelatihan atau jumlah frame help.
* Kehandalan: waktu rata-rata kegagalan, probabilitas ketidaksediaan, kecepatan
terjadinya kegagalan atau ketersediaan.
* Ketahanan: waktu start ulang setelah kegagalan, prosentase event yang gagal atau
probabilitas korupsi data.
* Portabilitas: prosentase peryataan tergantung target atau jumlah system target.
Dokumen Persyaratan Perangkat Lunak
Dokumen persyaratan perangkat lunak (SRS/Software Requirements Specification) merupakan
persyaratan resmi mengenai apa yang dituntut dari pengembang sistem. Dokumen berisi
persyaratan user untuk sistem dan spesifikasi secara rinci dari persyaratan sistem.
Berikut ilustrasi contoh dokumen persyaratan perangkat lunak dan bagaimana
pemanfaatannya

Pelanggan Sistem
Manajer

Menspesifikasikan persyaratan dan membacanya untuk memeriksa apakah sudah

memenuhi kebutuhan. Mereka menspesifikasi perubahan atas persyaratan tersebut
Menggunakan dokumen persyaratan untuk merencanakan penawaran atas sistem dan

merencanakan proses pengembangan sistem

Menggunakan persyaratan untuk memahami sistem apa yang akan dikembangkan

Perekayasa sistem
Perekayasa pengujian
Menggunakan persyaratan untuk mengembangkan pengujian validasi bagi sistem
sistem
Perekayasa
Menggunakan persyaratan untuk membantu memahami sistem dan hubungan antara
pemeliharaan sistem bagian bagiannya

Ian Sommerville dalam bukunya Software Engineering mengusulkan bahwa ada enam
persyaratan yang harus dipenuhi oleh dokumen persyaratan perangkat lunak yaitu:
- Menspesifikasi perilaku sistem eksternal.
- Menspesifikasi batasan batasan implementasi.
- Mudah diubah
- Berfungsi sebagai alat bantu referensi bagi pemelihara sistem.
Lembaga IEEE telah membuat standar untuk dokumen persyaratan perangkat lunak (IEEE/ANSI
830-1993). Berikut outline yang disarankan oleh IEEE untuk dokumen persyaratan
perangkat lunak:
1. Pendahuluan
1.1 Tujuan dokumen persyaratan
1.2 Cakupan produk
1.3 Definisi, akronim, dan singkatan
1.4 Referensi
1.5 Tinjauan bagian dokumen berikutnya
2. Deskripsi umum
2.1 Perspektif produk
2.2 Fungsi produk
2.3 Karakteristik user
2.4 Batasan-batasan umum
2.5 Asumsi dan ketergantungan
3. Persyaratan khusus
4. Lampiran
5. Indeks
Persyaratan khusus mencakup persyaratan fungsional, non-fungsional dan interface yang
merupakan bagian penting dari dokumen persyaratan perangkat lunak. Standar dari IEEE
memberikan saran apa saja yang perlu ditulis di dokumen persyaratan perangkat lunak,
tetapi pemanfaatannya tergantung dari kebutuhan pengembang dan pengguna perangkat lunak
tersebut.
Spesifikasi persyaratan user
Persyaratan User
Mendeskprisikan persyaratan fungsional dan non-fungsional sehingga dapat dipahami oleh
user yang tidak memiliki pengetahuan teknik. Persyaratan user harus ditulis memakai
bahasa natural formal dan diagaram intuitif yang sederhana. Persyaratan user tidak
boleh didefinisikan memakai model implementasi.
Masalah yang sering muncul:
- Tidak ada kejelasan
- Kesimpang-siuran persyaratan
- Penggabungan persyaratan
Spesifikasi
* User harus diberi fasilitas untuk mendefinisikan jenis file eksternal.
* Setiap file eksternal bisa memiliki alat bantu relevan yang bisa diterapkan pada file
tersebut.
* Setiap file eksternal bisa direpresentasikan sebagai ikon yang spesifik pada display
user.
* Fasilitas harus disediakan untuk ikon yang merepresentasikan suatu jenis file
eksternal yang akan didefinisikan oleh user.

* Ketika user memilih suatu ikon yang merepresentasikan file eksternal, efek pemilihan
adalah penerapan alat bantu yang berhubungan dengan jenis file eksternal ke file yang
direpresentasikan oleh ikon yang dipilih.
1. Jelaskan apa yang anda ketahui mengenai wawancara, skenario dan etnografi.
2. Jelaskan apa yang dipersiapkan dalam Pengesahan persyaratan.
3. Jelaskan fungsi Manajemen persyaratan.
1. Jelaskan apa yang anda ketahui mengenai wawancara, skenario dan etnografi.
Wawancara
Metode ini merupakan teknik pengumpulan requirement yang paling umum di lakukan. Teknis
dilapangan nya, sang pengembang atau develop menanyakan hal hal yang berkaitan dengan
masalah yang diangkat kepada responden yang memiliki kriteria yang cocok pada masalah
yang ditanyakan. Berikut langkah melakukan interview :
Memilih target interview
Mendesain pertanyan interview
Persiapan
Interview
Follow up
Wawancara secara Formal atau informal dengan pemegang taruhan menjadi bagian dari
paling tentang proses. Untuk menjadi pewawancaraan efektif, jadilah berpandangan
terbuka, menghindari pra ide terbenihkan sekitar persyaratan dan akan untuk
mendengarkan pemegang taruhan, Bisikkan orang sedang diwawancarai untuk memperoleh
pergi bahasan mempergunakan satu pertanyaan papan loncatan, satu usulan persyaratan,
atau dengan mengerjakan bersama-sama pada satu sistem contoh asli.
Skenario
Skenario adalah contoh kehidupan nyata dari bagaimana satu sistem dapat dipergunakan.
Skenario harus termasuk
- Satu uraian tentang keadaan awal;
- Satu uraian tentang aliran normal dari peristiwa;
- Satu uraian tentang apa yang dapat seleweng;
- Keterangan sekitar aktivitas berbarengan yang lain;
- Satu uraian tentang status ketika selesai skenario.
Etnografi
Etnografi berasal dari bahasa yunani, ethnes artinya rakyat sedangkan grapho
menulis. Jadi ethnography merupakan strategi atau metode penelitian ilmiah yang
sering digunakan dalam bidang ilmu sosial, khususnya dalam antropologi dan dalam
beberapa cabang sosiologi lainnya. Nilai etnografi membantu menemukan persyaratan
sistem yang implisit yang merefleksikan proses sebenarnya, bukan proses formal, dimana
orang orang terlibat.
Teknik teknik ethnography :
a) Penelitian Kuantitatif
b) Penelitian Kebijakan Publik
c) Jurnalisme
Menurut Denzim, ada 8 prinsip dalam metodologi ethnography, yaitu :
1) Kelompok kelompok harus menggabungkan makna simbolik dengan pola interaksi
2) Amati dunia / permasalahan dari sudut pandang subject
3) Merekam semua perilaku subject
4) Metodologi ini harus meliputi tahapan proses, perubahan dan stabilitas
5) Bertindak dengan interaksi simbolis sejenis
6) Melihat makna subject dengan hubungan sosial
7) Menggunakan konsep yang terperinci untuk menghindari penjelasan yang sulit.
8) Tetap menjaga perbedaan antara persepsi dan realitas.
Jelaskan apa yang dipersiapkan dalam Pengesahan persyaratan.
Yang dipersiapkan dalam Pengesahan persyaratan
Kebenaran. Apakah sistem menyediakan fungsi yang mana dukungan terbaik persyaratannya
pelanggan?
Konsistensi. Ada di sana apapun konflik persyaratan?
Kelengkapan. Adalah semua fungsi diperlukan oleh pelanggan termasuk?
Realisme. Dapat persyaratan menjadi tertentu yang penerapan anggaran keuangan
tersedia dan teknologi

 Verifiability. Dapat persyaratan menjadi diperiksa?

Jelaskan fungsi Manajemen persyaratan.

Manajemen persyaratan berfungsi dalam pengelolaan dan pengontrol bisnis, perubahan
organisatoris dan teknis yang tak bisa diacuhkan untuk mengubah ke persyaratan dalam
suatu sistem perangkat lunak.
Wawancara : wawancara formal dan informal dengan stakeholder berupa pertanyaanpertanyaan yang diajukan pada stakeholder.
Contoh: wawancara sistem informasi kereta api yang akan dibangun kepada petugas penjaga
kereta api
Skenario : contoh nyata bagaimana sistem digunakan, deskripsi situasi awal, kejadian
normal, kesalahan yang mungkin terjadi, aktifitas selanjutnya, kondisi ketika skenario
selesai.
Contoh : pengumpulan catatan medis pasien RS
Kasus penggunaan : teknis berbasis skenario UML yang mengidentifikasi aktor dan
interaksi dalam sistem
Contoh : Diagram sekuens sistem manajemen RS
Etnografi : Bertanya kepada ilmuwan sosial dan menganalisa orang bekerja sehingga
mereka tidak perlu menjelaskan. Contoh : bertanya pada ahli gempa untuk membuat sistem
informasi tentang gempa.
Pengertian Pemodelan Sistem
Pemodelan sistem adalah proses pengembangan abstrak model dari suatu sistem, dimana
setiap model menggambarkan pandangan yang berbeda atau perspektif dari sistem tersebut.
Sekarang pemodelan sistem dapat berarti merepresentasikan suatu sistem menggunakan
notasi grafis, dimana saat ini hampir selalu menggunakan notasi dari Unified Modeling
Language (UML). Pemodelan sistem membantu penganalisa untuk memahami fungsionalitas
sistem dan model biasanya digunakan untuk berkomunikasi dengan pelanggan.
Fungsi Pemodelan sistem
Fungsi pemodelan sistem terbagi dua, yaitu dari segi akademik dan manajerial
Dari segi akademik berfungsi untuk :
* Untuk menjelaskan sekumpulan fakta karena belum ada teori
* Untuk mencari konfirmasi, bila telah ada teori teori
Dari segi manajerial berfungsi untuk :
* Alat pengambilan keputusan
* Proses belajar
* Alat komunikasi
Tipe-tipe Diagram UML & dan d. contohnya
1.
Use Case Diagram
Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja
dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya
sendiri melalui sebuah cerita bagaimana sebuah system dipakai.
Contoh/bentuk diagram use case

Diagram

Use Case berguna dalam tiga hal :

Menjelaskan fasilitas yang ada (requirement)
Komunikasi dengan klien
Membuat test dari kasus-kasus secara umum

Aktivity Diagram
Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam
suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use
case individual, atau logika keputusan yang terkandung dalam metode individual.
Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel.
Contoh/bentuk diagram Aktivity

Pada dasarnya Diagram Aktifitas digunakan untuk menggambarkan al ur (aliran) yang

terjadi didalam sistem. Diagram ini menunjukan bagaimana aktifitas itu berlangsung, apa
yang dilakukan bila ada suatu kondisi, dan bagaimana aktifitas tersebut dapat selesai.
Notasi yang digunakan dalam activity diagram adalah sebagai barikut:
1.
Activity: Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam
aliran pekerjaan.
2.
Transition: Notasi yang digunakan untuk memperlihatkan jalan aliran control
dari activity ke activity.
3.
Decision: Notasi yang menandakan kontro cabang aliran berdasarkan decision
point.
4.
Synchronization bars: Aliran kerja notasi ini menandakan bahwa beberapa
aktivitas dapat diselesaikan secara bersamaan (pararel).
Sequence Diagram
Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu.
Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya
dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.
Contoh/bentuk diagram Sequence

Diagram Kolaborasi
Diagram kolaborasi diagram yang fungsinya sama dengan diagram interaksi (sekuen
diagram). tetapi terdapat hal yang membedakan antara diagram kolaborasi dengan diagram
interaksi yaitu penyusunannya, diagram kolaborasi lebih menekankan kepada struktur
aliran dari objek objek yang mengirim dan menerima pesan.
Contoh/bentuk diagram Kolaborasi

Component Diagram
Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk
menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya,
ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas
atau paket kelas akan berada pada node klien dan mana yang akan berada di server.
Contoh/bentuk diagram Komponen

komponen dasar pada sebuah sistem diantaranya yaitu :

Komponen user interface yang menangani tampilan sistem
Komponen business processing yang menangani fungsi fungsi proses bisnis
Komponen data yang menangani manipulasi data
Komponen security yang menangani keamanan sistem
Class Diagram (Class Diagram)
Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan
relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan
global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan
relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class
diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu
system.
Contoh/bentuk diagram Class

Kelas merupakan sebuah objek dimana dalam kelas diagram, kelas diwakilkan dengan kota
yang berisi tiga bagian diantaranya yaitu :
1.
Nama Kelas
2.
Atribut Kelas, merupakan informasi mengenai objek atau kelas
yang disimpan atau setidaknya dipertahankan sementara.
3.
Methode, merupakan hal hal atau operasi yang dapat dilakukan oleh suatu objek
atau kelas
4.
Visibilitas, merupakan visibility dari tiap atribut atau operator pada suatu
kelas. Berikut ini adalah visibilitas yang dapat digunakan
Jelaskan mengenai Model Konteks, Model Interaksi, Model Struktural, Model Tingkah Laku,
Model-driven Rekayasa,
Model Konteks
Model konteks biasanya digunakan untuk mengilustrasikan keadaan (konteks) operasional
dari sistem hal ini memperlihatkan apa saja yang ada di luar batas sistem.
Perhatian masyarakat dan organisasi mungkin mempengaruhi keputusan pada memposisikan
batasan-batasan sistem.
Model arsitektur (Architectural models) memperlihatkan sistem dan hubungannya dengan
sistem lain.
Model Interaksi
Pemodelan interaksi pengguna adalah sangat penting karena membantu identifikasi
persyaratan (kebutuhan) pengguna.
Pemodelan interaksi sistem ke sistem menyoroti masalah komunikasi yang mungkin
timbul.
Pemodelan interaksi komponen membantu kita memahami jika struktur sistem yang
diusulkan sesuai dengan pemenuhan kebutuhan kinerja sistem dan ketergantungannya.
Use case diagrams and sequence diagrams mungkin digunakan untuk pemodelan interaksi.

Model struktural
Model struktural dari perangkat lunak menampilkan organisasi dari sistem dalam
kaitannnya dengan komponen-komponen pembentuk sistem dan hubungan-hubungannya.
Model struktural mungkin model statis, yang memperlihatkan struktur dari desain
sistem, atau model dinamis, yang memperlihatkan organisasi dari sistem ketika sedang
dijalankan.
Anda membuat model struktural dari sistem ketika Anda kamu sedang mendiskusikan dan
mendisain arsitektur sistem.
Model tingkah laku
memodelkan perilaku dinamis dari sistem dan bagaimana merespon ke tindakan (events).
Model driven Rekayasa
Dalam proses rekayasa model-driven, memungkinkan untuk menghasilkan implementasi
sistem lengkap atau parsial dari pemodelan sistem tersebut.

Diskusikan mengenai Alat-alat bantu perancangan terstruktur yang digunakan oleh sistem
analis sbb:
- Document Flowchart
- System Flowchart
- ICAM
- DFD
- DOCUMENT FLOWCHART
DOCUMENT FLOWCHART
Document Flowchart menelusuri alur dari data yang ditulis melalui sistem. Document
Flowchart sering disebut juga dengan Flowchart Dokumen.
Kegunaan utamanya adalah untuk menelusuri alur form dan laporan sistem dari satu bagian
ke bagian lain baik bagaimana alur form dan laporan diproses, dicatat dan disimpan.
Contoh :
suatu contoh flowchart ini mengenai alur pembuatan kartu anggota untuk suatu
perpustakaan.

Keterangan:
# : proses pengisian data
P : tanda tangan dan validasi data
System Flowchart / FLowchart System
Flowchart Sistem merupakan bagan yang menunjukkan alur kerja atau apa yang sedang
dikerjakan di dalam sistem secara keseluruhan dan menjelaskan urutan dari prosedurprosedur yang ada di dalam sistem. Dengan kata lain, flowchart ini merupakan deskripsi
secara grafik dari urutan prosedur-prosedur yang terkombinasi yang membentuk suatu
sistem.
Flowchart Sistem terdiri dari data yang mengalir melalui sistem dan proses yang
mentransformasikan data itu. Data dan proses dalam flowchart sistem dapat digambarkan
secara online (dihubungkan langsung dengan komputer) atau offline (tidak dihubungkan
langsung dengan komputer, misalnya mesin tik, cash register atau kalkulator).
Diagram Alir Data (DAD) atau Data Flow Diagram (DFD) adalah suatu diagram yang
menggunakan notasi-notasi untuk menggambarkan arus dari data sistem, yang penggunaannya
sangat membantu untuk memahami sistem secara logika, tersruktur dan jelas. DFD
merupakan alat bantu dalam menggambarkan atau menjelaskan DFD ini sering disebut juga
dengan nama Bubble chart, Bubble diagram, model proses, diagram alur kerja, atau model
fungsi.
Tujuan DFD adalah :

1. Memberikan indikasi mengenai bagaimana data ditransformasi pada saat data bergerak
melalui sistem
2. Menggambarkan fungsi-fungsi(dan sub fungsi) yang mentransformasi aliran data
Manfaat DFD adalah :
Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional
sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang
dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.
DFD ini adalah salah satu alat pembuatan model yang sering digunakan,khususnya bila
fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data
yang dimanipulasi oleh sistem.Dengan kata lain, DFD adalah alat pembuatan model yang
memberikan penekanan hanya pada fungsi sistem.
DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan
konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem
yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat
program.
Contoh DFD Pemesanan Baju Online :

-ICAM
IDEF, merupakan istilah akronim majemuk (ICAM Definition Function Modeling, dan
'ICAM' sendiri adalah singkatan dari Integrated Computer Aided Manufacturing). IDEF
adalah metodologi fungsi pemodelan untuk menggambarkan fungsi manufaktur, yang
menawarkan bahasa pemodelan fungsional untuk analisis, pengembangan, rekayasa ulang,
dan integrasi sistem informasi; proses bisnis, atau analisis rekayasa perangkat lunak.
IDEF0 merupakan bagian dari keluarga bahasa pemodelan IDEF di bidang rekayasa
perangkat lunak, dan dibangun pada pemodelan fungsional bahasa Analisis Terstruktur dan
Teknik Desain. Pemodelan aktivitas IDEF (Integration Definition for Function) cocok
untuk pendokumentasian proses bisnis yang menyediakan sudut pandang konteks tingkat
tinggi, dan juga sudut pandang yang didetailkan pada setiap langkah dalam aktivitas
dalam format yang dapat didekomposisi lebih lanjut dan dihubungkan dengan proses
lainnya untuk menunjukkan kaitannya. Tipe diagram ini berguna untuk menunjukkan
hubungan antara langkah langkah dan pengaruh internal/eksternal, tetapi tidak
mengindikasikan urutan waktu.

- Definisi perancangan Arsitektur Perangkat Lunak.

- Keuntungan perancangan Arsitektur Perangkat Lunak.
- Metode Analisis Software Architecture
Tujuan Perancangan
Secara umum tujuan dari perancangan adalah untuk menghasilkan suatu model atau
penggambaran dari suatu entitas yang akan dibangun, dimana dengan menggunakan hasil
perancangan tersebut dapat diketahui tingkah laku sistem yang akan dibangun, sehingga
pemakai dapat mengetahui kesesuaian sistem yang akan dibangun dengan keseluruhan
kebutuhan yang diajukan oleh pihak pemakai (customer).
Perancangan Arsitektur Perangkat Lunak
Perancangan Arsitektur Perangkat Lunak merupakan suatu tahapan yang berkaitan dengan
modul-modul, dan fungsi-fungsi yang di representasikan menjadi sebuah bagan
terstruktur.
1.Perancangan Struktur Data
Tahap perancangan struktur data dimaksudkan untuk mendeskripsikan data-data atau
atribut suatu sistem, yang kaitannya dengan basis data yang dipakai.
2.Perancangan Antarmuka
Perancangan antarmuka pemakai atau User Interface merupakan suatu media komunikasi
antara sistem komputer dengan pemakai, rancangan ini dimaksudkan agar programmer mudah
dalam mengimplementasikan seluruh hasil rancangan ke dalam program.
3.Perancangan Algoritma
Algoritma merupakan suatu logika yang menjelaskan tahap perancangan sebelumnya, yaitu
perancangan arsitektur perangkat lunak, selain itu pembuatan pseudecode ini dimaksudkan
untuk membantu programmer dalam menyelesaikan tugasnya, yaitu pada tahap setelah
perancangan, yaitu tahap penulisan program atau coding.
4.Penulisan Program (Coding)
Setelah selesai melakukan langkah demi langkah pada tahap perancangan, tahap
selanjutnya adalah tahap implementasi atau tahap pembuatan program. Tahap ini merupakan
tahap akhir penyelesaian pembuatan perangkat lunak, pada tahap ini semua hasil analisis
dan perancangan diimplementasikan ke dalam sebuah lingkungan program dengan menentukan
lingkungan implementasi yang akan digunakan, pengelolaan basis data, atau dapat
dikatakan tahap ini merupakan tahap representasi dari seluruh hasil analisis dan
perancangan ke dalam dunia nyata.

- Definisi perancangan Arsitektur Perangkat Lunak.

Sistem-sistem besar selalu diuraikan menjadi sistem-sistem yang memberikan set layanan
yang berhubungan. Proses perancangan awal untuk mengidentifikasi subsistem ini dan
menetapkan kerangka kerja untuk control dan komunikasinya disebut Perancangan
Arsitektur .
Arsitektur Perangkat Lunak merupakan Gambaran bagaimana elemen/komponen fungsional
perangkat lunak disusun, diorganisasi dan distrukturkan sehingga: Hubungan antar
elemen/komponen dapat dijelaskan, Interface yang menghubungkan elemen/komponen dapat
didefinisikan, Wujud dan penempatan elemen/komponen dalam tempat penyimpanan sekunder
secara fisik dapat ditetapkan.
Jadi dapat disimpulkan bahwa Perancangan Arsitektur Perangkat Lunak merupakan suatu
tahapan yang berkaitan dengan modul-modul, dan fungsi-fungsi yang di representasikan
menjadi sebuah bagan terstruktur.
Keuntungan perancangan Arsitektur Perangkat Lunak.
Komunikasi stakeholder.
Arsitektur merupakan presentasi tingkat tinggi dari sistem yang dapat digunakan sebagai
fokus pembahasan oleh stakeholder.
Analisa Sistem.

Analisa sistem dilakukan untuk membuat keputusan perancangan arsitektural yang memiliki
efek sangat besar mengenai kinerja, keandalan, dan kemampuan dapat dipelihara.
Pemakaian ulang berskala besar.
Arsitektur dapat ditransfer melintasi sistem dengan persyaratan yang sama dan dengan
demikian dapat mendukung pemakaian ulang perangkat lunak berskala besar. Pendidikan
Teknik Informatika dan Komputer Universitas Negeri Makassar
Metode Analisis Software Architecture
Metode Analisis Arsitektur Software adalah metode yang digunakan dalam arsitektur
perangkat lunak untuk mengevaluasi arsitektur sistem. Atau metodologi yang digunakan
untuk menentukan bagaimana kualitas atribut aplikasi spesifik yang dicapai dan
bagaimana kemungkinan perubahan di masa depan akan mempengaruhi kualitas atribut
berdasarkan kasus studi hipotesis. Atribut kualitas umum yang dapat dimanfaatkan oleh
metodologi ini termasuk kemampuan modifikasi, ketahanan, portabilitas, dan jangka
panjang.
1.
2.
3.
4.

Diskusikan tujuan dari testing/pengujian perangkat lunak.

Metode yang digunakan dalam testing/pengujian perangkat lunak.
Mana metode yang menurut anda paling baik digunakan.
Jelaskan prinsip Pareto.

Tujuan dari testing/pengujian perangkat lunak adalah menjalankan program untuk

menemukan error/bug yang tersembunyi atau yang sebelumnya tidak terduga.
Metode Pengujian Perangkat Lunak
Pengujian Black Box
Teknik pengujian tanpa memiliki pengetahuan tentang cara kerja dalam bagian aplikasi
ini disebut Black Box pengujian. Tester ini mempunyai arsitektur sistem dan tidak
memiliki akses ke kode sumber. Biasanya, saat melakukan tes black box, tester akan
berinteraksi dengan user interface sistem dengan memberikan masukan dan memeriksa
output tanpa mengetahui bagaimana dan di mana input bekerja.
Pengujian White Box
Pengujian white box adalah penyelidikan rinci dari logika internal dan struktur kode .
Pengujian white box disebut juga pengujian kaca atau pengujian kotak terbuka.
Pengujian Grey Box
pengujian grey box adalah teknik untuk menguji aplikasi dengan pengetahuan yang
terbatas tentang cara kerja aplikasi internal.
Prinsip Pareto(juga dikenal sebagai aturan 80-20) menyatakan bahwa untuk banyak
kejadian, sekitar 80% daripada efeknya disebabkan oleh 20% dari penyebabnya.
Prinsip ini diajukkan oleh pemikir manajemen bisnis Joseph M. Juran, yang menamakannya
berdasarkan ekonom Italia Vilfredo Pareto (15 July 1848 19 August 1923), yang pada
1906 mengamati bahwa 80% dari pendapatan di Italia dimiliki oleh 20% dari jumlah
populasi.
Dalam implementasinya, prisip 80/20 ini dapat diterapkan untuk hampir semua hal:
80%
80%
20%
20%
20%

dari
dari
dari
dari
dari

keluhan pelanggan muncul dari 20% dari produk atau jasa.

keterlambatan jadwal timbul dari 20% dari kemungkinan penyebab penundaan.
produk atau jasa mencapai 80% dari keuntungan.
tenaga penjualan memproduksi 80% dari pendapatan perusahaan.
cacat sistem menyebabkan 80% masalah.

Dalam ilmu komputer dan teori kontrol rekayasa seperti untuk konverter energi
elektromekanis, prinsip Pareto dapat diterapkan untuk upaya optimasi. Sebagai contoh,
Microsoft mencatat bahwa dengan menetapkan atas 20% paling melaporkan bug, 80% dari
kesalahan dan crash akan dihilangkan.
Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan
yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program.
Dalam pengembangan perangkat lunak proses yang khas adalah bahwa pengumpulan
persyaratan, persyaratan review, desain, desain review, coding, kode review, pengujian
komponen, pengujian integrasi, rilis, dan pemeliharaan. Singkatnya, proyek mulai dengan

satu set persyaratan, dan kemudian pergi melalui serangkaian perbaikan dimana
spesifikasi asli dibandingkan dengan produk akhir untuk kelengkapan dan kebenaran dan
terhadap penggunaan dunia nyata untuk perbaikan tambahan. Selama revisi, jika
persyaratan dari proses pembangunan mengikuti distribusi Pareto, maka beberapa isu
kunci akan menampakkan diri dan perlu ditangani pada setiap revisi baru. Persyaratan
lama akan memudar , dan yang baru akan muncul dengan konteks mereka sendiri .
Praktis pengalaman memberitahu kita bahwa pada awal proyek perangkat lunak masalah
tersebut mencakup isu-isu tersebut pada platform pilihan, bahasa implementasi, database
model data, modus akses dan fungsi utama dari aplikasi. Seiring waktu, penyempurnaan
lanjutan dapat memperkenalkan persyaratan yang membahas bagaimana aplikasi bekerja
untuk kelompok tertentu pengguna, atau dalam konsep dengan aplikasi eksternal lainnya.
Menurut saya yang paling baik digunakan adalah Metode White Box karena White Box adalah
meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur
logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan
kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil
kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar
secara 100%.
1.
2.
3.
4.

Pengertian Sociotechnical systems (STS)

Lapisan-lapisan dalam `STS` Stack
Prinsip-prinsip dalam desain STS
Tujuan Perancangan Sistem Holistic

Sistem tekhnikal sosial (sociotechnical system) merupakan faktor atau aspek sosial
yang berkaitan dengan implementasi teknologi (teknis) dalam pengembangan suatu sistem.
Sebuah produk perangkat lunak tidak hanya berkutat dengan masalah yang berhubungan
dengan teknologi (teknis), bahkan sering sebuah produk perangkat lunak hanya dibuat
atau dikembangkan berdasarkan sudut pandang pengembang perangkat lunak yang memiliki
kecenderungan berpola pikir teknik

LAPISAN
Perangkat (Equipment)
Alat perangkat keras, beberapa yang iantaranya mungkin komputer. Kebanyakan peralatan
termasuk sistem yang melekat (embdded systems) atau semacamnya.
Sistem operasi
Menyediakan seperangkat fasilitas umum dengan bahasa tingkat tinggi (higher level)
dalam sistemnya.
Manajemen komunikasi dan data
`Middleware` yang menyediakan akses ke sistem remote dan basis data.
Sistem aplikasi
Fungsional spesifik yang memenuhi kebutuhan-kebutuhan organisasi.
Proses bisnis
Seperangkat proses yang melibatkan orang dan sistem komputer yang mendukung
aktivitas bisnis.
Organisasi
Aktifitas-aktifitas bisnis strategis tingkat tinggi yang mempengaruhi operasi dari
sistem.
Masyarakat (Society)
Hukum, peraturan dan budaya yang mempengaruhi operasi dari siste
Prinsip-prinsip dalam desain STS
Kompatibilitas (compatibility)
Spesifikasi Kritis (Critical Specification)
Kriteria Sosio-Teknis (The Socio-Technical Criterion)
Men-support Harmonisasi (Support Congruence)
Disain dan Nilai Kemanusiaan (Design and Human Values)
Tujuan Perancangan Sistem Holistic adalah Untuk dapat diandalkan (dependability),
karena perspektif sistem adalah penting

1. Tujuan Analisa Resiko dan Manajemen Resiko.

2. Mengapa Proyek Perangkat Lunak Gagal?
3. Jelaskan Resiko pada Perangkat Lunak.
1. Tujuan Analisa Resiko dan Manajemen Resiko.
Tujuan analisis resiko yaitu membantu tim proyek dalam mengembangkan strategi yang
berkaitan dengan resiko. Strategi yang efektif harus memiliki gagasan berikut :
1. Menghindari resiko, yaitu denga pendekatan proaktif terhadap resiko
2. Monitoring resiko, yaitu :
a. Memonitoring faktor faktor yang dapat memberikan suatu indikasi apakah resiko
sedang menjadi lebih atau kurang mungkin
b. memonitor efektivitas langkah pengurangan resiko
3. Manajemen resiko dan perencanaan kemungkinan, mengasumsikan bahwa usaha pengurangan
telah gagal dan bahwa resiko telah menjadi kenyataan
Tujuan dari Manajemen Resiko adalah untuk memperkecil resiko yang akan terjadi ketika
kita membuat atau menjalankan suatu proyek.
Tujuan utama manajemen resiko adalah mengenali semua kemungkinan kegagalan dari suatu
proyek perangkat lunak dengan melihat kekomplekan dalam memutuskan langkah solusi yang
akan dibuat secara alami [Boehm, B. W. 1998].
2. Mengapa Proyek Perangkat Lunak Gagal?
Proyek perangkat lunak sering tidak berhasil. Menurut sebuah penelitian, tingkat
kegagalan proyek perangkat lunak berskala besar bisa mencapai 50% hingga 80 %. Data
tersebut bisa saja belum menggambarkan realitas sesungguhnya, mengingat sifat alami
manusia yang cenderung suka menyembunyikan kabar buruk, sehingga kondisi riilnya bisa
lebih besar dari angka itu.
Menurut Standish Report (USA), outcome sebuah software engineering project dapat
dikelompokkan dalam 3 katagori :
1. Successful, dimana proyek tersebut bisa selesai tepat waktu dengan biaya yang tidak
berubah dan menghasilkan feature & function seperti yang diharapkan.
2. Challanged, dimana proyek tersebut bisa diselesaikan dan mampu beroperasi baik,
namun waktu penyelesaiannya molor, biaya membengkak dengan feature & function yang
lebih sedikit dari yang direncanakan semula.
3. Failed, dimana proyek dihentikan ketika masih dalam siklus pengembangan dengan
alasan tidak lengkapnya daftar kebutuhan (requirement) yang diinginkan. Tentu saja
produk perangkat lunaknya tidak pernah diimplementasikan dan dibongkar dari instalasi.
Mengapa Proyek Perangkat Lunak Gagal?
Sebagai gambaran betapa masih tingginya tingkat kegagalan proyek perangkat lunak di
negara yang telah maju sekalipun, tabel berikut menunjukkan perkembangan tingkat
keberhasilan proyek pengembangan perangkat lunak (software development project) di
Amerika Serikat dari tahun ke tahun :

Dampak kegagalan seperti yang dilaporkan Standish Report tersebut berakibat pada
pemborosan SDM dan peralatan, hilangnya dana klien, kerugian instalasi, bahkan
hilangnya sebuah kehidupan. Dan ketika diproses di lembaga hukum, aduannya banyak
dimentahkan oleh pihak pengadilan. Padahal biaya peradilannya sendiri seringkali lebih
besar dari pada coding cost yang dipermasalahkan itu. Dan sekalipun telah lebih dari 12
tahun berselang, seperti dalam laporan terbaru Standish Report (2006), bahwa proyek
perangkat lunak yang dibuat mulai 2006 yang berkatagori sukses baru beranjak ke level

35% (dari 16,2 % di tahun 1994). Ini berarti baru 35% dari proyek perangkat lunak yang
bisa selesai tepat waktu, tepat biaya dan memenuhi kebutuhan user. Lebih lanjut
dilaporkan bahwa proyek yang sama sekali gagal turun menjadi 19% (dari 31,1% ditahun
1994), sedangkan proyek yang termasuk dalam kelompok challenged turun menjadi 46% (dari
kisaran 52,7% di tahun 1994).
2. Mengapa Proyek Perangkat Lunak Gagal?
Berdasarkan Versi OXPORD University
Sebuah kajian yang lain dilakukan oleh laboratorium komputer OXPORD University, yang
menyebutkan bahwa ketidakberhasilan sebuah proyek perangkat lunak banyak disebabkan
karena :
1. Kegagalan mengkomunikasikan permintaan klien dengan anggota team desain inti.
2. Kurangnya metode yang dapat menjamin requirement statement yang konsisten, akurat
dan lengkap.
3. Ketidakmampuan mengatasi perubahan (evolusi) permintaan klien (user).
Penelitian tersebut juga berhasil menyimpulkan bahwa biang kegagalan sebuah proyek
perangkat lunak yang paling umum adalah ketidakberhasilan dalam mendefinisikan
permintaan klien secara akurat. Dan kesalahan yang sering terjadi selama ini bukan
karena suatu faktor yang misterius, melainkan kesalahan yang baru diketahui di
kemudian hari setelah proses pengembangan perangkat lunak telah berubah cukup jauh.
Solusi mengatasi resiko perangkat lunak.
Kita harus memanajemen resiko, seperti mengidentifikasi dan menganalisa resiko
Penanganan resiko:
a. High probability, high impact: resiko jenis ini umumnya dihindari ataupun
ditransfer.
b. Low probability, high impact: respon paling tepat untuk tipe resiko ini adalah
dihindari. Dan jika masih terjadi, maka lakukan mitigasi resiko serta kembangkan
contingency plan.
c. High probability, low impact: mitigasi resiko dan kembangkan contingency plan.
d. Low probability, low impact: efek dari resiko ini dapat dikurangi, namun biayanya
dapat saja melebihi dampak yang dihasilkan. Dalam kasus ini mungkin lebih baik untuk
menerima efek dari resiko tersebut.

1.
2.
3.
4.

Pengertian Perangkat Lunak guna ulang (Software reuse).

Keuntungan dan Kerugian Perangkat Lunak guna ulang.
Pendekatan-pendekatan Yang Mendukung Perangkat Lunak Guna Ulang.
Contoh aplikasi yang menggunakan Software reuse.

1. Pengertian Software reuse

Software reuse disebut juga code reuse adalah penggunaan software yang sudah ada, atau
pengetahuan software (software knowledge) untuk membangun software baru. Di banyak
disiplin ilmu teknik, sitem dibangun dengan menyusun componen yang sudah ada dan telah
digunakan pada system lain. Software engineering lebih difokuskan pada pembangunan
software secara asli, tapi sekarang untuk mendapatkan hasil software yang lebih baik,
lebih cepat dan harga murah, kita membutuhkan mengadopsi proses yang didasarkan pada
konsep software reuse. Reuse telah di praktikkan semenjak hari pertama memprogram.
Programmer selalu memggunakan kembali (reuse) sebagian dari code, template, fungsi, dan
procedure. Software reuse telah diterima kedalam area belajar software engineering.
Item dari reusable software atau software knowledge disebut sebagai software asset.
Asset mungkin adalah desain, model tes, kebutuhan kebutuhan, arsitektur, dll.
Reuse didasarkan pada software engineering
a. Application system reuse Sebuah aplikasi besar pada sebuah sistem mungkin digunakan
tanpa merubah ke sistem lain atau membangun aplikasi yang mirip.
b. Component reuse Penggunaan dari komponen sebuah aplikasi.
c. Object and function reuse Pengunaan komponen software berupa objek atau fungsi.

2. Keuntungan dan kerugian software reuse

Keuntungan software reuse.
a. Meningkatkan kepercayaan Software yang akan digunakan kembali telah di tes dan
dicoba pada sistemnya, sehingga lebih bisa dipercaya dari
software baru. awal
pembuatan dari software mendeteksi berbagai kesalahan desain dan implementasi. Ini
kemudian diperbaiki, yang megurangi tingkat kegagalan saat software di gunakan kembali.
b. Mengurangi resiko Jika sotware telah ada, ada pengurangan biaya dalam pembuatan
software. Ini adalah factor yang penting untuk manajemen proyek untuk mengurang
estimasi biaya proyek disisi kesalahan software. Hal ini lebih terlihat saat sejumlah
besar komponen software digunakan kembali.
c. Lebih efektif untuk para spesialis Para spesialis tidak perlu melakukan pekerjaan
yang sama pada proyek berbeda. Para spesialis bisa menggunakan software sebelumnya
dengan mengkapsulasi program mereka.
d. Standar pelaksanaan Beberapa standar, seperti standar user interface, bisa
diimplementasikan sebagai standard reusable component. Sebagai contoh interface menu
bisa diimplementasikan memggunakan reusable component, semua aplikasi menyajikan format
menu yang sama. Standar interface ini meningkatkan keyakinan user untuk mengurangi
kesalahan ketika medapati interface yang familiar.
e. Percepatan pengembangan Membawa software ke pasaran secepat mungkin adalah lebih
penting dari semua biaya pengembangan. Reuse softrware dapat mempercepat produksi
karena waktu pengembangan dan pengesahan software bisa dikurangi.
- Kekurangannya adalah seperti permasalahan berikut
a. Meningkatkan biaya perawatan Biaya perawatan mungkin akan bertambah saat reuse
elemen dari suatu sistem memjadi semakin tidak sesuai dengan perubahan system.
b. Kekurangan tool pendukung Toolset mungkin tidaksupport pembangunan software dengan
model reuse. Ini mungkin sulit atau tidak mungkin untuk mengintegrasi tool dengan
sistem component library.
c. Sindrome Not-Invented-here Beberapa software engineer kadang kadang lebih suka
menulis ulang reuse component sebagian dengan alasan dapat meningkatkan kegunaan
reusable component, sebagian melakukan dengan kepercayaan bahwa fakta menulis original
software adalah lebih menantang dari menggunakan software orang lain.
d. Membuat dan merawat komponen library Menyusun sejumlah reusable componenet library
dan menjamin pengembang bisa mengunakan library ini bisa menjadi mahal. Teknik umum
kita untuk mengklasifikasi, mengkatalog, dan megambil komponen software adalah belum
tepat.
e. Menemukan, mengerti dan mengadaptasikan komponen reusable Komponen software harus
ditemukan di library, dimengerti dan, kadang, diadaptasikan untuk bekerja di lingkungan
baru. Engineer harus yakin untuk menemukan komponen di library sebelum mereka akan
menyertakan komponen sebagai bagian dari proses pembangunan software mereka. Software
library adalah contoh yang bagus sebagai abstraksi. Programmer mungkin memutuskan untuk
membuat abstraksi internal sehingga bagian dari program mereka bisa digunakan kembali,
atau mungkin membuat library untuk digunakan sendiri. Untuk penggunaan code yang sudah
ada, beberapa hal seperti interface, atau jalur komunikasi, harus didefinisikan. Ini
umumnya termasuk penggunaan subroutine, object, class, atau prototype. Praktik seperti
ini di formalisasi dan distandarisasi oleh software product line engineering. Praktek
yang umum adalah pengunaan versi terdahulu dari program yg ada sebagai titik mulai dari
versi selajutnya juga disebut dengan software reuse.
3. Pendekatan-pendekatan Yang Mendukung Perangkat Lunak Guna Ulang.
-

Service-oriented systems
software product lines
COTS product reuse
ERP systems
Configuable vertical applications
Program libraries

- Model driven engineering

- program generator
- Aspect oriented software development
Landasan software reuse (reuse landscape)
Meskipun reuse sering disederhanakan sebagai sebuah komponen sistem, ada banyak
pendekatan berbeda untuk menggunakan kembali software. Reuse dimungkinkan untuk selang
level dari fungsi simple sampai aplikasi komplit. landscape reuse memberi landasan
pemahaman dalam pengaplikasian reuse.
a. Design patterns (Pola desain) : Abstraksi umum yang terjadi dalam memperesentasikan
aplikasi dalam sebuah desain yang menunjukkan astraksi umum, objek konkret dan
interaksi.
b. Component-based development (pembangunan berbasis komponen) : system dibangun dengan
mengintegrasikan komponen yang sesuai dengan model standar komponen.
c. Aplication framework (Kerangka aplikasi) : koleksi dari abstrak dan class konkret
yang bisa diadaptasikan dan diperluas untuk membuat aplikasi system.
d. Legacy system wrapping : kebijaksaaan sistem yang bisa disatukan dengan
mendefisniskan seset interface dan menyediakan akses ke kebijaksanaan system ini
melalui interface.
e. Service oriented system (system berorientasi service) : sistem yang dibangun dengan
menghubungkan share service yang mungkin disediakan pihak luar.
f. Application product lines : sebuah tipe aplikasi yang umum pada arsitekture software
sehingga bisa diadaptasiakan dengan cara berbeda utuk costumer berbeda.
g. Program libraries (Program library) : Library Class dan function yang
mengimplementasikan code yang siap digunakan.
h. Program generators : Sebuah generator system yang bisa menghsilkan system atau
software dengan menspesifikasikan type parameter / hasil yang diinginkan.
4. Contoh aplikasi yang menggunakan Software reuse
Contoh yang umum dari software reuse adalah Teknik penggunaan software library.
Banyak operasi umum seperti konversi informasi diantara format yang berbeda, mengakses
simpanan luar, berkomunikasi dengan external program, atau memanipulasi informasi
(angka, kata, nama, lokasi., tanggal, dll) yang sering dibutuhkan oleh berbagi program
berbeda. Pembuat program baru bisa menggunakan kode pada software library untuk
melakukan tugas tertentu, bukan sebaliknya dengan menulis penuh program untuk melakukan
tugas / operasi yg diinginkan.
Implementasi dari libarary sering kali memberi keuntungan dalam menyelesaikan kasus
yang tidak biasa.
Diskusikan mengenai:
1. Manajemen Konfigurasi.
2. Manajemen perubahan
3. Manajemen versi
4. Manajemen Release

1. Manajemen Konfigurasi.
Dalam rekayasa perangkat lunak , manajemen konfigurasi perangkat lunak (SCM) adalah
tugas pelacakan dan mengendalikan perubahan dalam perangkat lunak. Praktek manajemen
Konfigurasi termasuk kontrol revisi dan pembentukan garis .
SCM keprihatinan sendiri dengan menjawab pertanyaan Seseorang melakukan sesuatu,
bagaimana seseorang dapat mereproduksi itu? Seringkali masalah melibatkan tidak
berkembang biak itu identik, tetapi dengan dikontrol, perubahan bertahap. Menjawab
pertanyaan itu dengan demikian menjadi masalah yang berbeda dan membandingkan hasil
analisis perbedaan mereka. Manajemen konfigurasi tradisional biasanya berfokus pada
penciptaan dikontrol produk relatif sederhana. Sekarang, pelaksana SCM menghadapi
tantangan yang berkaitan dengan peningkatan relatif kecil di bawah kendali mereka
sendiri, dalam konteks sistem yang kompleks dikembangkan.
Tujuan dari SCM umumnya :

* Konfigurasi identifikasi Mengidentifikasi konfigurasi, item konfigurasi dan

baseline .
* Konfigurasi DNS Menerapkan proses perubahan dikendalikan. Hal ini biasanya dicapai
dengan membentuk sebuah kontrol papan perubahan fungsi utamanya adalah untuk menyetujui
atau menolak permintaan mengubah semua yang dikirim terhadap dasar apapun.
* Konfigurasi status akuntansi Pencatatan dan pelaporan semua informasi yang
diperlukan tentang status proses pembangunan.
* Konfigurasi audit Memastikan bahwa konfigurasi berisi semua bagian yang dimaksudkan
mereka dan suara sehubungan dengan dokumen mereka menentukan, termasuk persyaratan,
spesifikasi arsitektur dan buku petunjuk.
* manajemen Bangun Mengelola proses dan alat yang digunakan untuk membangun.
* Proses manajemen Memastikan kepatuhan terhadap proses pembangunan organisasi.
* Lingkungan manajemen Mengelola perangkat lunak dan perangkat keras sistem host kita
* Teamwork tim Memfasilitasi interaksi yang berhubungan dengan proses.
* Pelacakan Cacat Memastikan setiap cacat mampu telusur kembali ke sumbernya.
2. Manajemen perubahan
Manajemen perubahan perangkat lunak adalah hal yang mengatur ,mengidentifikasi,
mengontrol perubahan (modifikasi) perangkat lunak, dan mengontrol faktor penyebab
terjadinya perubahan perangkat lunak berikut :
- Bisnis baru atau kondisi pasar yang menjadikan perubahan pada kebutuhan produk atau
aturan bisnis.
- Kebutuhan pelanggan (customer) baru yang menyebabkan perubahan permintaan data oleh
sistem informasi, fungsi yang ada pada produk, atau layanan (service) yang diberikan
oleh sistem berbasis komputer.
- Re-organisasi dan/atau perubahan bisnis yang menyebabkan perubahan dalam prioritas
proyek atau struktur tim rekayasa perangkat lunak (software engineering).
- Batasan anggaran dan jadwal yang menyebabkan redefinisi sistem atau produk.
Kegiatan kontrol perubahan (Change Control) :
- Untuk proyek pengembangan perangkat lunak yang besar, perubahan cepat yang tidak
terkontrol akan membawa - kekacauan.
- Kontrol perubahan adalah kombinasi prosedur manusia dan tool yang otomatis
menyediakan mekanisme untuk mengontrol perubahan.
- Permintaan perubahan diisikan dan dievaluasi untuk menguji faktor teknik, potensial
efek samping, dampak keseluruhan pada objek konfigurasi lain dan fungsi sistem dan
biaya yang diproyeksikan dari perubahan.
- Hasil dari evaluasi dipresentasikan sebagai laporan perubahan yang digunakan oleh
Change Control Authority (CCA) yakni orang atau grup yang membuat keputusan final dalam
status dan prioritas perubahan.
3. Manajemen Versi
- Manajemen versi (VM) adalah proses penjejakan perbedaan versi dari komponen
perangkat lunak atau item konfigurasi dan sistem dimana komponen ini dipergunakan.
- Hal tersebut juga melibatkan memastikan perubahan yang dibuat oleh pengembang
berbeda pada versi-versi tersebut tidak mencampur-adukkan satu sama lain.
- Oleh sebab itu manajemen versi dapat dipikirkan dari sebagai proses dari
pengelolaan `codelines` dan garis dasar.
Kegiatan kontrol versi (Version Control) :

- Kontrol versi mengkombinasikan prosedur dan tool untuk mengatur versi yang berbeda
dari konfigurasi objek yang dibuat selama proses rekayasa perangkat lunak.
- Manajemen konfigurasi meminta pengguna untuk menspesifikasi konfigurasi alternatif
dari sistem perangkat lunak pada saat seleksi versi yang tepat.
4. Manajemen Release
Manajemen pelepasan (release)
Mempersiapkan perangkat lunak untuk pelepasan keluar dan menjejaki versi sistem yang
telah dilepaskan untuk penggunaan pelanggan.
1.
2.
3.
4.

Kualitas perangkat lunak

Standar perangkat lunak
Ulasan dan inspeksi
Pengukuran perangkat lunak dan metrik

1. Defenisi Kualitas Perangkat Lunak

Kualitas merupakan kata yang meragukan dan dibutuhkan untuk definisi yang secara
hati-hati untuk dimaknai. Untuk sistem perangkat lunak apapun, seharusnya ada 3
spesifikasi yaitu :
- Spesifikasi
utama metodologi
- Spesifikasi
- Spesifikasi
sistem

fungsional Menggambarkan apa yang dikerjakan sistem, merupakan fokus

seperti Unified Software Development Process
kualitas (atribut), Fokus pada bagaimana fungsi beroperasi.
sumber daya, Fokus pada seberapa banyak yang harus dihabiskan oleh

Beberapa kualitas dapat diidentifikasi untuk menghasilkan perangkat lunak yang

mencerminkan pandangan eksternal perangkat lunak yang akan diliki user, sebagaimana
pada kasus usability. Kualitas eksternal akan dipetakan ke faktor internal dimana
developer akan bersikap waspada. Hal ini bisa diperdebatkan, misalnya kode yang
tersusun dengan baik (well-constructed code) umumnya memiliki kesalahan lebih sedikit
dan peningkatan kemampuan untuk digunakan.
Mendefinisikan kualitas tidak cukup hanya dengan jika kita melakukan keputusan
yang sesuai dengan kebutuhan sistem sehingga kita perlu melakukan pengukuran kualitas.
Untuk setiap karakteristik kualitas, satu atau lebih pengukuran yang ditemukan akan
menghasilkan nilai derajat kualitas.
Pengukuran yang baik harus dapat menghubungkan jumlah unit sampai keadaan yang
maksimal. Jumlah maksimum kesalahan pada program, misalnya kesalahan yang berhubungan
dengan ukuran program sehingga pengukuran kesalahan per seribu baris kode (fault per
thousand line of code) akan lebih membantu daripada jumlah kesalahan (total fault) pada
program sebagai jaminan kualitas program.
Mencoba untuk menemukan pengukuran untuk kualitas tertentu membantu
mengklarifikasi apakah kualitas itu. Yang dipertanyakan adalah, dampak terhadap
Bagaimana kita mengetahui kapan hal ini akan berhasil? menjawab tentang sasaran
kualitas akan dijelaskan lebih lanjut.
Kemungkinan pengukuran kualitas dapat dilakukan secara langsung atau indirect
dimana sesuatu yang diukur bukan kualitasnya sendiri tetapi indikator kualitas yang
dihadirkan. Misalnya jumlah permintaan oleh user diterima dengan bantuan pengoperasian
aplikasi perangkat lunak tertentu dapat menjadi pengukuran usability secara indirect.
Dengan identifikasi manajemen pengukuran pengaturan program bagi tim anggota proyek
sangat penting untuk meningkatkan kualitas pengukuran itu sendiri. Misalnya jumlah
kesalahan yang ditemukan di baris program tidak bisa dihitung, pada dasarnya hal itu
memerlukan proses pemeriksaan yang lebih teliti, sehingga kesalahan lebih mudah
ditemukan.

Standar perangkat lunak

Standar Kualitas IS0 9000
Sistem jaminan kualitas dapat didefinisikan sebagai struktur, tanggung jawab,
prosedur, proses, dan sumber-sumber daya organisasi untuk mengimplementasi manajemen
kualitas. IS0 9000 menjelaskan elemen jaminan kualitas dalam bentuk yang umum yang
dapat diaplikasikan pada berbagai bisnis tanpa memandang produk dan jasa yang
ditawarkan. Elemen-elemen tersebut mencakup struktur, prosedur, proses, organisasi, dan
sumber daya yang dibutuhkan untuk mengimplementasi rencana kualitas, kontrol kualitas,
jaminan kualitas, dan pengembangan kualitas. Agar terdaftar dalam satu model sistem
jaminan kualitas yang ada pada IS0 9000, sistem kualitas dan operasi perusahaan
diperiksa oleh auditor untuk memeriksa kesesuaiannya dengan standar dan operasi
efektif. Bila registrasi itu berhasil, perusahaan diberi sertifikasi dari badan
registrasi yang diwakili oleh auditor. Audit pengawasan tengah tahunan terus dilakukan
untuk memastikan kesesuaiannya dengan standar yang sudah ditetapkan.
Standar IS0 9001
IS0 9001 adalah standar jaminan kualitas yang berlaku untuk rekayasa perangkat
lunak. Standar tersebut berisi 20 syarat yang harus ada untuk mencapai sistem jaminan
kualitas yang efektif, yaitu :
1. Tanggung jawab manajemen
2. Sistem kualitas
3. Kajian kontrak
4. Kontrol desain
5. Kontrol data dan dokumen
6. Pembelian
7. Kontrol terhadap produk yang disuplai oleh pelanggan
8. ldentifikasi dan kemampuan penelusuran produk
9. Kontrol proses
10. Pemeriksaan dan pengujian
11. Kontrol pemeriksaan, pengukuran, dan perlengkapan pengujian
12. Pemeriksaan dan status pengujian
13. Kontrol ketidaksesuaian produk
14. Tindakan preventif dan korektif
15. Penanganan, penyimpanan, pengepakan, preservasi, dan penyampaian
16. Kontrol terhadap catatan kualitas
17. Audit kualitas internal
18. Pelatihan
19. Pelayanan
20. Teknik statistik
Pengukuran perangkat lunak dan metrik
Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan
kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement)
adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut
IEEE adalah ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses
memiliki atribut tertentu.
Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah
kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak
menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari
jumlah kesalahan yang ditemukan pada setiap kajian.
Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi
sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan
dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri.
Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat
lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.
PENGUKURAN PERANGKAT LUNAK
Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi,
ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan
pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas,

kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.Dalam kenyataannya,

pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena
ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas
proyek.
Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik
perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang
lebih besar.
Pengukuran perangkat lunak dan metrik
METRIK
Metrik digunakan oleh industri perangkat lunak untuk mengukur proses pembuatan,
operasi, dan perawatan perangkat lunak. Melalui metrik, dapat diperoleh informasiinformasi berharga dan parameter-parameter sebagai bahan evaluasi yang obyektif
mengenai atribut-atribut dan status dari suatu pengembangan perangkat lunak.
Implementasi metrik perangkat lunak pada suatu proses pengembangan perangkat lunak dan
pada suatu produk perangkat lunak melibatkan tahapan-tahapan kompleks yang memerlukan
pembelajaran yang berkelanjutan, yang pada akhirnya dapat memberikan pengetahuan
mengenai status dari suatu proses pembuatan perangkat lunak dan atau suatu produk dari
perangkat lunak
Metrik perangkat lunak memiliki batasan-batasan yang luas. Metrik perangkat lunak
tergantung pada atribut-atribut perangkat lunak yang ingin dinilai kuantitas dan
kualitasnya.
Secara umum, metrik perangkat lunak dibagi dalam dua kelas yang berbeda, yaitu
metrik yang digunakan pada proyek pengembangan perangkat lunak dan metrik yang
digunakan pada produk perangkat lunak. Metrik pada proyek pengembangan perangkat lunak
berhubungan dengan tenaga dan pikiran yang diperlukan untuk menyelesaikan proyek,
sumber daya yang digunakan untuk menyelesaikannya, dan metodologi yang diterapkan,
misalnya: waktu yang diperlukan untuk menyelesaikan, tenaga ahli yang diperlukan,
biaya-biaya yang dikeluarkan, dan metodologi yang digunakan dalam pembuatan perangkat
lunak.