MAKALAH

Rekayasa Perangkat Lunak

Disusun Oleh : Maulana Akhsan (4611412010)

UNIVERSITAS NEGERI SEMARANG SEMARANG 2014

KATA PENGANTAR Assalamualaikum warahmatullahi wabarakatuh. Alhamdulillahirabbilalamin, banyak nikmat yang Allah berikan, tetapi sedikit sekali yang kita ingat. Segala puji hanya layak untuk Allah Tuhan seru sekalian alam atas segala berkat, rahmat, taufik, serta hidayah-Nya yang tiada terkira besarnya, sehingga penulis dapat menyelesaikan makalah dengan judul Rekayasa Perangkat Lunak. Dalam penyusunannya, penulis memperoleh banyak bantuan dari berbagai pihak, karena itu penulis mengucapkan terima kasih yang sebesar-besarnya Dari sanalah semua kesuksesan ini berawal, semoga semua ini bisa memberikan sedikit kebahagiaan dan menuntun pada langkah yang lebih baik lagi. Meskipun penulis berharap isi dari makalah ini bebas dari kekurangan dan kesalahan, namun selalu ada yang kurang. Oleh karena itu, penulis mengharapkan kritik dan saran yang membangun agar makalah ini dapat lebih baik lagi. Akhir kata penulis berharap agar makalah ini bermanfaat bagi semua pembaca.

Semarang, 6 Maret 2014 ( Maulana Akhsan )

BAB 1 PENDAHULUAN 1.1 Latar Belakang Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software Engineering. Istilah Software Engineering dipopulerkan tahun 1968 pada Software Engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer. 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 (OBrien, 1999). Pengertian RPL sendiri adalah sebagai berikut: Suatu di siplin Ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai memelihara system setelah di gunakan. Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan semua aspek produksi pada pengertian di atas, mempunyai arti semua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL. 1.2 Rumusan Masalah 1. 2. 3. 4. 5. Konsep Dasar RPL? Kebutuhan dan Spesifikasi Perangkat Lunak? Validasi Perangkat Lunak Evolusi Perangkat Lunak Pengelolaan Proyek Perangkat Lunak

BAB 2 PEMBAHASAN 1. Konsep Dasar Rekayasa Perangkat Lunak Konsep dasar rekayasa perangkat lunak mempunyai dua hal pokok yaitu perangkat lunak (software) dan komponen perekayasa. Menurut IEEE definisi perangkat lunak (software) merupakan program komputer, prosedur, data dan semua dokumentasi yang berhubungan operasi pada sistem komputer. jadi bisa disimpulkan bahwa software merupakan kumpulan dari object membentuk konfigurasi yang didalamnya termasuk program, dokumen, dan data. Sedangkan Perekayasa software bertugas mengembangkan produk perangkat lunak, yang secara produk dapat dikategorikan menjadi 2 tipe yaitu : a. Produk generik Sistem stand-alone, produk shrink-wrapped b. Produk pesanan Produk custemisasi, terdapat proses interaksi antara pemesan dan pembuat. Rekayasa perangkat lunak dapat didefinisikan sebagai disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga mencakup kegiatan manajemen proyek perangkat lunak dan pengembangan alat bantu, metode dan teori untuk mendukung produksi perangkat lunak. Secara umum rekayasa perangkat lunak memakai pendekatan yang sistematis dan terorganisir dengan menggunakan metode tertentu. 2. Kebutuhan dan Spesifikasi Perangkat Lunak 2.1 Analisis Kebutuhan Perangkat Lunak Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning. Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia , perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak. Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat

dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting. Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua metode analisis memiliki prinsip analisis yang sama, yaitu : 1. Menggambarkan domain informasi masalah 2. Mendefinisikan fungsi perangkat lunak 3. Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang dibagi secara rinci pada sebuah model lapisan (hirarki) 4. Informasi pokok pada tahap analisis memudahkan tahap implementasi yang lebih rinci. Tujuan tahap analisis adalah : 1. Menjabarkan kebutuhan pemakai 2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak 3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna). 1) Apa yang Disebut Kebutuhan (Requirement) Pengertian Kebutuhan Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu yang dibutuhkan. Sedangkan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah : Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai sebuah objek. Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan. Tahap kebutuhan akan perangkat lunak dimulai dengan : 1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian. Identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (product improvement oriented). 2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah kemajuan). Ada dua jenis kebutuhan : 1. Behavioral apa yang dilakukan oleh sistem (input dan output dari dan ke sistem). hubungan informasi antara input dan output sehingga menghasilkan sebuah fungsi transformasi. 2. Non-behavioral Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan tersebut.

Termasuk deskripsi lengkap tentang efisiensi, keamanan (security), rehability maintenability (bagaimana perawatan untuk sistem), dan portability (bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya). Mengapa Kebutuhan Penting ? Perhatikan gambar dampak kumulatif berikut ini :

Mencari kesalahan diakhir siklus hidup pengembangan perangkat lunak ternyata akan banyak mengeluarkan uang. Jika dapat dideteksi, dilakukan perbaikan pada setiap tahap proses. Jika tidak dapat dideteksi, kesalahan baru kelihatan setelah produk selesai dibuat. 2) Tahap Analisis Kebutuhan Perangkat Lunak Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas : 1. Menentukan kebutuhan (requirement) Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur. Data atau informasi apa yang akan diproses Fungsi apa yang diinginkan Kelakuan sistem apa yang diharapkan Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software interface, dan communications interfaces)

2. Sintesis Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan memanfaatkan teknik dan metodeanalisis tertentu. 3. Membuat dokumen Software Requirements Spesification (SRS). Sudah merupakan analisis yang lebih rinci, sebagai tahap awal perancangan. 3) Metode Analisis Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut. 1. Berorientasi Aliran Data (Data Flow Oriented atau Functional Oriented) Sudut pandang analisis pada pendekatan ini difokuskan pada aspek fungsional dan behavioral (perilaku laku) sistem. Pengembang harus mengetahui fungsi-fungsi atau proses-proses apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebuat, dan apa yang menjadi hasil transformasinya. Selain itu pengembang harus mengetahui keadaan (state), perubahan (transition), kondisi (condition), dan aksi (action) dari sistem. Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur (Structured Analysis) yang dikembangkan oleh Tom DeMarco, Chris Gane dan Trish Sarson, dan Edward Yourdon . Pada metode ini, hasil analisis dan perancangan dimodelkan dengan menggunakan beberapa perangkat permodelan seperti : Data Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk menggambarkan fungsi-fungsi dari sistem. Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan (data storage). State Transition Diagram (STD) untuk menggambarkan perilaku sistem. Structure Chart untuk menggambarkan struktur program 2. Berorientasi Struktur Data Analisis pendekatan ini difokuskan pada struktur data, dimana struktur tersebut dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan repetition. Beberapa metode berorientasi struktur data ini diantaranya adalah : Data Structured System Development (DSSD) Diperkenalkan pertama kali oleh J.D. Warnier [1974] dan kemudian oleh Ken Orr [1977], sehingga sering disebut juga metode Warnier-Orr. Metode ini menggunakan perangkat entity diagram, assembly line diagram dan Warnier Orr diagram untuk memodelkan hasil analisis dan rancangannya. Jackson Sistem Development (JSD) Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat ng disebut strukture diagram dan sistem spesification diagram.

3. Berorientasi objek Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata. Pada pendekatan ini, informasi dan proses yang dipunyai oleh suatu objek dienkapsulasi (dibungkus) dalam satu kesatuan. Beberapa metode pengembangan sistem yang berorientasi objek ini diantaranya adalah : Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad dan Edward Yourdon [1990]. Object Modelling Technique (OMT) dari James Rumbaugh [1987]. Object Oriented Software Engineering (OOSE) 2.2 Sepesifikasi Kebutuhan Perangkat Lunak Spesifikasi kebutuhan perangkat lunak atau Software Requirements Spefication (SRS) adalah sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak. Suatu SRS harus mencantumkan tentang deskripsi dengan lingkungannya. Mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai. SRS bisa terdiri dari banyak dokumentasi yang saling melengkapi. Suatu SRS harus dapat : 1. Menguraikan definisi masalah 2. Menguraikan masalah dengan tepat dengan cara yang tepat pula

Objektif SRS 1. Persetujuan kerja dengan pelanggan 2. Daftar kebutuhan teknis yang harus dipenuhi oleh perangkat lunak Syarat Pembentukan SRS 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) Hindari hal-hal berikut saat pembentukan SRS 1. Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas) 2. Tindakan unconcistency 3. Ambiguity dalam kata atau kalimat 4. Menuliskan mimpi-mimpi , yaitu hal-hal yang tidak bisa dilakukan Dalam Suatu SRS ada 2 aspek yang harus bisa dilihat :

1. Fungsi Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa), sifat lunak dan datanya. 2. Non-Fungsi a. Dependability reliability maintainbility security integrity b. Ergonomic c. Performance d. Contraint Atribut Suatu SRS 1. Benar (correct) Jika salah (incorrect), artinya spesifikasi yang ditulis adalah bukan yang diinginkan. 2. Tepat (precise) Berpengaruh pada hasil perancangan dan pembuatan software requirements design (SRD). 3. Unambiguouity Setiap permintaan harus punya satu interpretasi, atau hanya ada satu arti dalam satu kalimat. 4. Lengkap (complete) Lengkap jika dilihat dari dua sudut pandang : Dokumen membuat tabel isi, nomor halaman, nomor gambar, nomor tabel, dan sebagainya. 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 spesifik misalnya diminta A tetap ditulis A. 7. Understandable Dapat dimengerti oleh pemrograman, analisis sistem atau sistem 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 menjelaskan what tadi)

11. Dapat mencakup dan melingkupi seluruh sistem 12. Dapat melingkupi semua lingkungan operasional, misalny interaksi fisik dan operasional. 13. Bisa menggambarkan sistem seperti yang dilihat oleh pemakai. 14. Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan ketidak konsistenan. 15. Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat. Ada 9 macam orang yang terlibat dalam pembuatan 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 analyst (sistem engineer) Yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement. 4. Software engineer Yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan sistem engineer berdasarkan SRS) 5. Programmaer Menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul. 6. Test integration group Kumpulan orang yang melakukan tes dan mengintegrasi modul. 7. Maintenance group Memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan). 8. Technical Support Orang-orang yang mengelola (manage) pengembang perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi. 9. Staff dan Clerical Work Bertugas mengetik, memasukkan data dan membuat dokumen. Keberhasilan pengembangan perangkat lunak bisa dilihat dari 10 aspek atau titik pandang, yaitu : 1. Ketelitian dari pembuatnya 2. Kualitas dari spesifikasi perangkat lunaik yang dihasilkan (Baik, jika ada sedikit kesalahan). 3. Integritas 4. Ketelitian 5. Proses Pembuatan yang mantap 6. Mudah dikembangkan 7. Jumlah versi yang tidak banyak

8. Ketelitian dari model pengembangan yang digunakan untuk meramal atribut perangkat lunak 9. Efektivitas rencana tes dan integrasi 10. Tingkat persiapan untuk sistem perawatan (mempersiapkan pencarian bugs) Contoh Layout Dokumen SRS 1. PENDAHULUAN 1.1. Tujuan 1.2. Ruang Lingkup 1.3. Definisi 1.4. Referensi 1.5. Sistematika 2. DESKRIPSI UMUM 2.1. Perspektif 2.2. Kegunaan 2.3. Karakteristik Pengguna 2.4. Batasan-batasan 2.5. Asumsi dan Ketergantungan 3. SPESISIKASI KEBUTUHAN 3.1. Kebutuhan Fungsional 3.1.1. Pendahuluan 3.1.2. Input 3.1.3. Proses 3.1.4. Output 3.2. Kebutuhan Antarmuka Eksternal 3.2.1. Antarmuka Pengguna 3.2.2. Antarmuka Perangkat Keras 3.2.3. Antarmuka Perangkat Lunak 3.2.4. Antarmuka Komunikasi 3.3. Kebutuhan Performasi 3.4. Kendala Desain 3.4.1. Standard Compliance 3.4.2. Perangkat Keras 3.5. Atribut 3.5.1. Keamanan SIstem 3.5.2. Pemeliharaan 3.6. Kebutuhan Lain 3.6.1. Database 3.6.2. Pengoperasian 3.6.3. Penyesuaian Tempat

3. Verifikasi dan Validasi Perangkat Lunak Verifikasi adalah proses pemeriksaan apakah logika operasional model (program komputer) sesuai dengan logika diagram alur. Kalimat sederhananya, apakah ada kesalahan dalam program? (Hoover dan Perry, 1989); verifikasi adalah pemeriksaan apakah program komputer simulasi berjalan sesuai dengan yang diinginkan, dengan pemeriksaan program komputer. Verifikasi memeriksa penerjemahan model simulasi konseptual (diagram alur dan asumsi) ke dalam bahasa pemrograman secara benar (Law dan Kelton, 1991). Validasi adalah proses penentuan apakah model, sebagai konseptualisasi atau abstraksi, merupakan representasi berarti dan akurat dari sistem nyata? (Hoover dan Perry, 1989); validasi adalah penentuan apakah mode konseptual simulasi (sebagai tandingan program komputer) adalah representasi akurat dari sistem nyata yang sedang dimodelkan (Law dan Kelton,1991). Perangkat Lunak Merupakan program-program komputer dan dokumentasi yang berkaitan. Produk perangkat lunak dibuat untuk pelanggan tertentu ataupun untuk pasar umum Produk perangkat lunak mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya dan menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia

BAB 3 PENUTUPAN

Ayi Purbasari, S.T., M.T. Unpas - 2007/2008

Ketika membangun model simulasi sistem nyata, kita harus melewati beberapa tahapan atau level pemodelan. Seperti yang dapat dilihat pada Gambar diatas, pertama kita harus membangun model konseptual yang memuat elemen sistem nyata. Dari model konseptual ini kita membangun model logika yang memuat relasi logis antara elemen sistem juga variabel eksogenus yang mempengaruhi sistem. Model kedua ini sering disebut sebagai model diagram alur. Menggunakan model diagram alur ini, lalu dikembangkan program komputer,

yang disebut juga sebagai model simulasi, yang akan mengeksekusi model diagram alur. Pengembangan model simulasi merupakan proses iteratif dengan beberapa perubahan kecil pada setiap tahap. Dasar iterasi antara model yang berbeda adalah kesuksesan atau kegagalan ketika verifikasi dan validasi setiap model. Ketika validasi model dilakukan, kita mengembangkan representasi kredibel sistem nyata, ketika verifikasi dilakukan kita memeriksa apakah logika model diimplementasikan dengan benar atau tidak. Karena verifikasi dan validasi berbeda, teknik yang digunakan untuk yang satu tidak selalu bermanfaat untuk yang lain. Baik untuk verifikasi atau validasi model, kita harus membangun sekumpulan kriteria untuk menilai apakah diagram alur model dan logika internal adalah benar dan apakah model konseptual representasi valid dari sistem nyata. Bersamaan dengan kriteria evaluasi model, kita harus spesifikasikan siapa yang akan mengaplikasikan kriteria dan menilai seberapa dekat kriteria itu memenuhi apa yang sebenarnya. 4. Evolusi Perangkat Lunak Pengembangan perangkat lunak dapat dibagi menjadi 4 tahap, yaitu : Tahap Pertama (1950 1960) Evolusi perangkat lunak tahap pertama dimulai pada awal 1950-an sampai pertengahan 1960. Pengembangan perangkat lunak pada tahap pertama mempunyai ciri-ciri berorientasi batch, distribusisoftware terbatas untuk kalangan tertentu sehingga apabila ada perusahaan yang ingin dibuatkan software khusus harus memesan terlebih dahulu. Tahap Kedua ( 1960 1970) Evolusi Perangkat Lunak Tahap Kedua dimulai pertengahan tahun 1960-an sampai awal tahun 1970-an. Pengembangan perangkat lunak mempunyai ciri-ciri multi user. Pengguna dari software sudah banyak dan bisa saling berbagi. Ciri ini menunjukkan ada perkembangan baru yaitu interkasi manusia dan komputer (Human Computer Interaction). Selain itu, ciri dari tahap kedua ini adalah real time. Real Time disini adalah suatu kondisi dimana sistem dapat mengumpulkan, menganalisa dan mentransformasikan data dari banyak sumber kemudian mengatur proses serta menghasilkan output yang diinginkan. Dalam tahap ini, sudah banyak juga paket perangkat lunak yang beredar di pasaran serta muncul istilah database dalam perangkat lunak.

Tahap Ketiga (1970 1990) Evolusi Perangkat lUnak tahap ketiga, dimulai pertengahan tahun 1970 sampai awal tahun 1990. Pengembangan perangkat lunak sudah maju sedemikian pesat. Perangkat lunak sudah menggunakan sistem terdistribusi, sehingga penyampaian informasi dari komputer sumber ke komputer tujuan akan terasa sangat cepat. Dalam era ini, perangkat keras dari suatu komputer harganya sangat murah. Selain itu, pesanan perangkat lunak sudah sangat mendominasi dari penyelesaian suatu masalah sehingga penggunaan software pada masa itu sudah sedemikian jauh. Tahap Keempat (1990 2000) Evolusi Perangkat Lunak Tahap Keempat dimulai tahun 1990 sampai tahun 2000. Pada tahap ini, perangkat lunak sudah mendominasi dari pengembangan perangkat keras, sehingga perangkat keras dalam hal ini komputer sangat dikendalikan oleh suatu sistem operasi. TIngkat kecerdasan dari perangkat lunak semakin ditingkatkan sehingga perangkat lunak atau software dilatih mempunyai kecerdasan seperti yang dimilik manusia. Terbukti dengan adanya penemuan kecerdasan buatan, jaringan syaraf tiruan, sistem pakar dan logika fuzzy. Jaringan komputer, pemrosesan komputer paralel sangat mendominasi pada era ini. Dan, pada masa ini pula pemrograman sudah berorientasi obyek (OOP). 5. Pengelolaan Proyek Perangkat Lunak Manajemen proyek perangkat lunak merupakan bagian yang penting dalam pembangunan perangkat lunak. Sekalipun tidak bersifat teknis seperti pengkodean, hal-hal dalam manajemen proyek PL ini mampu menentukan apakah proyek akan berjalan dengan baik sehingga menghasilkan produk yang baik. Hal-hal yang berkaitan dengan manajemen adalah pengelolaan personel dan koordinasi tim, proses, pengukuran proyek-termasuk menentukan harga dari PL, penjadwalan dan sebagainya. Dalam pembahasan berikut, hanya sebagian kecil dari manajemen yang akan dibahas untuk memberi gambaran tentang hal-hal manajemen yang berlaku dan diterapkan dalam pembangunan PL. Manajemen Personel, Produk dan Proses Manajemen proyek perangkat lunak mengatur 4 hal penting: personel, produk, proses dan proyek. Empat hal ini berurutan mulai dari yang paling penting. Personel merupakan mendapat tempat paling penting karena tanpa personel yang baik dan tepat maka 3 hal lain tidak bisa berjalan dengan baik.

Katagori Personel Proses pembangunan PL melibatkan banyak personel. Personel-personel ini digambarkan seperti pemain, dan dikatagorikan dalam 5 katagori pemain: 1. manajer senior : yang menentukan usaha yang dikerjakan, dan pemegang keputusan dalam proyek. 2. manajer proyek (teknis) pemimpin tim: yang membuat rencana, memotivasi, mengatur dan mengendalikan praktisi yang mengerjakan PL 3. praktisi : yang mengerjakan PL 4. klien : yang menentukan kebutuhan PL dan pihak lain yang berkaitan dengan hasil produk 5. pengguna PL : yang berinteraksi langsung dengan PL yang dibangun. Efektifitas kerja masing-masing personel di atas harus diusahakan oleh pemimpin tim. Pemimpin tim ini yang mengatur tim proyek agar dapat memberikan yang terbaik dari masing-masing personel. Pemimpin Tim Pemimpin Tim PL disini adalah manager proyek. Seorang pemimpin tim diharuskan mempunyai ketrampilan memimpin yang cukup. Seseorang tidak menjadi pemimpin tim secara kebetulan tapi sungguh-sungguh karena punya kemampuan. Kemampuan yang dibutuhkan dalam kepemimpinan seperti: - mampu memotivasi Rekayasa Perangkat Lunak Teknik Informatika UKDW - mampu berorganisasi : . mengatur proses yang ada atau membuat yang baru dalam rangka mewujudkan ide/konsep menjadi produk - mampu mendorong keluarnya ide-ide baru: memberi dorongan, menciptakan situasi yang kondusif untuk lahirnya ide baru - mencari penyelesaian masalah (problem solving): mampu menganalisa masalah-masalah teknis ataupun manajemen/organisasi kemudian mendapatkan jalan keluar atau memotivasi anggota untuk mampu menyelesaikan masalah. Akomodatif terhadap perubahan yang mungkin terjadi - mampu menjadi manajer: menggunakan wewenangnya pada saat yang tepat, atau memberikan kebebasan pada anggota timnya jika diperlukan - mampu menghargai kerja: menghargai hasil yang dicapai, ide yang dilontarkan dan pendapat yang diajukan oleh anggota timnya - mampu mengenali tim: mampu membaca dan memahami anggota timnya. Mampu memenuhi kebutuhan tim dan bertahan dalam tekanan yang tinggi.

Tim Perangkat Lunak (Software Team) Struktur organisasi dalam tim ini bisa mengadaptasi dari banyak struktur organisasi yang sudah ada. Berikut beberapa pilihan pembagian tugas/penugasan yang bisa diterapkan untuk tim perangkat lunak yang terdiri dari n personel yang bekerja selama k tahun: - n personel ditugaskan untuk sejumlah m tugas yang berbeda dengan sedikit tugas gabungan koordinasi adalah tugas dari manajer yang mungkin saja punya 6 proyek lainnya. - n personel di tugaskan untuk sejumlah m tugas yang berbeda dengan m < n sehingga terbentuk tim informal. Pemimpin tim khusus perlu ada koordinasi antar tim adalah tanggung jawab manajer - n personel dibagi menjadi sejumlah t tim. Tiap tim ditugaskan mengerjakan satu atau lebih tugas. Tiap tugas mempunyai struktur yang ditentukan sebelumnya bagi semua tim koordinasi dikendalikan oleh tim dan manager . Sekalipun masing-masing pilihan punya argumentasi sendiri-sendiri, namun dari pengamatan yang dilakukan, pilihan no 3 dianggap lebih produktif. Cara atau gaya manajemen, jumlah personel, tingkat kemampuan para personel dan masalahmasalah yang dihadapi tim menentukan bentuk struktur organisasi yang bisa diterapkan. Contoh struktur organisasi tim adalah: 1. Democratic Decentralized (DD) : Tidak ada pemimpin yang permanen, koordinator ditunjuk untuk jangka waktu yang pendek, keputusan diambil berdasarkan konsensus bersama, komunikasi horizontal antar anggota tim (posisi sejajar semua) cocok untuk masalah yang sulit/rumit, cocok untuk proyek besar, tim cenderung awet dan bertahan lama, pekerjaan memuaskan, cocok untuk masalah yang modularitasnya rendah, perlu banyak waktu untuk menyelesaikan proyek, 2. Controlled decentralized (CD) : Pemimpin tim ditentukan, ada wakil pemimpin dan mereka berbagi tugas, penyelesaian masalah adalah tugas tim dan implementasinya dibagi di antara beberapa sub-tim oleh pemimpin, komunikasi horisontal di antara sub-tim dan di antara personel, komunikasi vertikal berdasarkan struktur hirarki sentralisasi untuk penyelesaian masalah, cocok untuk masalah yang sederhana, cukup cocok untuk proyek besar, masalah dengan modularitas tinggi, menghasilkan sedikit kesalahan 3. Controlled Centralized (CC): penyelesaian masalah dikerjakan oleh pemimpin, pemimpin melakukan koordinasi internal tim, komunikasi lebih banyak vertikal antara pemimpin dan anggota tim cocok untuk masalah yang sederhana, melakukan penyelesaian, masalah lebih cepat, masalah dengan modularitas tinggi, menghasilkan sedikit kesalahan.

BAB 3 PENUTUPAN
3.1 KESIMPULAN

DAFTAR PUSTAKA
http://bloktutorial.blogspot.com/2011/12/verifikasi-dan-validasi-perangkat-lunak.html http://trisnowlaharwetan.wordpress.com/2010/03/11/evolusi-perangkat-lunak/ Coad, Peter and Edward Yourdan. 1991. Object Oriented Analysis. New Jersey : Prentice Hall. Coad, Peter and Edward Yourdan. 1991. Object Oriented Design. New Jersey : Prentice Hall. Goodland, Mike. 1995. SSADM A Practical Approach Version 4. London : Mc Graw Hill Handoko, Mary. 1999. Bahan Kuliah Manajemen Proyek Perangkat Lunak. Bandung : Magister Informatika ITB Jacobson, I. 1995. Object Oriented Software Engineering. Edinburg Gate Harlow : Addison Wesley. Laksmiwati, Hira. 1998. Bahan-bahan Kuliah Rekayasa dan Analisis Perangkat Lunak. Bandung : Magister Informatika ITB Leman. 1998. Metodologi Pengembangan Sistem Informasi. Jakarta : Elex Media Komputindo Lorent, M and J Kidd. 1994. Object Oriented Sotfware Metrics. New Jersey : Prentice Hall. Mahyuzir, Tavri D. 1989. Analisisa Elex Media Komputindo dan Perancangan Sistem Pengolahan Data. Jakarta :

Mahyuzir, Tavri D. 1991. Pengantar Analisis dan Perancangan Perangkat Lunak. Jakarta : Elex Media Komputindo Mardiyanto, M. Sukrisno 1998. Bahan-bahan Kuliah Pembangunan Sistem Perangkat Lunak. Bandung : Magister Informatika ITB Santoso. Oerip S. 1999. Bahan-bahan Kuliah Uji Kualitas Perangkat Lunak. Bandung : Magister Informatika ITB Sucahyo, Yudho Giri. 1997. Bahan Kuliah Rekayasa Perangkat Lunak. Jakarta : Ilmu Komputer UI

Suharto, Toto. 2001. Diktat Kuliah Rekayasa Perangkat Lunak. Bandung : STT Telkom Pressman, Roger S. 1997. Software Engineering. New York : Mc Graw Hill. Rumbaugh, J. 1991. Object Oriented Modeling and Design. Edinburg Gate Harlow : Addison Wesley. Pressman, Roger.S. "Software Engineering : A Practioner's Approach." 5th . McGrawHill. 2001.