Kamis, 28 April 2016

Perencanaan Proyek Perangkat Lunak

1. OBSERVASI PADA ESTIMASI

Estimasi yang diperlukan dalam perancangan proyek perangkat lunak di antaranya adalah sumber daya, biaya, dan jadwal sebagai usaha dalam pengembangan perangkat lunak, mengakses informasi historis yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Berikut adalah yang menimbulkan ketidakpastian dalam estimasi :
– Project complexity (kompleksitas proyek) berpengaruh kuat terhadap ketidakpastian yang inheren dalam perencanaan. Komplekitas ini merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan dengan usaha yang dilakukan sebelumnya. – Project size (Ukuran proyek) Merupakan faktor penting yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan di antara berbagai elemen perangkat lunak akan meningkat dengan cepat.
– Structural uncertainty (Ketidakpastian struktural) Tingkat ketidakpastian strutural juga berpengaruh dalam risiko estimasi. Dengan melihat kembali, kita dapat mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat dimana masalah muncul.
Risiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya, biaya, dan jadwal.Bila ruang lingkup proyek atau syarat proyek tidak dipahami dengan baik, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface(yang diisikan ke dalam spesifikasi sistem). Pendekatan-pendekatan rekayasa perangkat lunak modern (seperti model proses evolusioner) memakai pandangan pengembangan yang interaktif. Dengan pandangan semacam ini dimungkinkan untuk melihat estimasi dan merevisinya bila customer mengubah kebutuhannya.

2. TUJUAN PERENCANAAN PROYEK

Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.

3. RUANG LINGKUP PERANGKAT LUNAK

Penentuan ruang lingkup perangkat lunak merupakan aktivitas pertama dalam perencanaan proyek perangkat lunak. Ruang lingkup perangkat lunak menggabarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dalam statmen ruang lingkup dievaluasi dan disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai. Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan ini mengidentifikasi dari batas yang ditempatkan pada perangkat lunak oleh perangkat keras eksternal, memori, atau sistem informasi yang ada.
3.1  MENCARI INFORMASI YANG DIBUTUHKAN UNTUK RUANG LINGKUP
Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan. Gause & weinberg mengusulkan bahwa analis harus memulai dengan mengajukan pertanyaan-pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan membawa pada pemahaman mendasar terhadap masalah, orang yang menginginkan suatu solusi, sifat solusi yang diharapkan, dan efektivitas pertemuan itu. Beberapa pertanyaan bebas konteks pada pelanggan yang meliputi tujuan keseluruhan, serta keuntungan :
o Siapa di belakang permintaan kerja ini?
o Siapa yang akan memakai solusi ini?
o Apakah yang akan menjadi keutungan ekonomi dari sebuah solusi yang sukses? o Adakah sumberdaya lain bagi solusi ini?
Beberapa contoh pertanyaan yang memungkinkan analis untuk memahami masalah lebih baik :
o Bagaimanakah anda menandai output yang baik yang akan dimunculkan oleh sebuah solui yang baik?
o Masalah apa yang akan dituju oleh solusi ini?
o Dapatkah anda memperlihatkan atau menggambarkan lingkungan di mana solusi akan dipakai?
o Adakah batasan atau isu kinerja khusus yang akan mempengaruhi cara pendekatan terhadap solusi?
Beberapa pertanyaan yang berfokus pada efektivitas pertemuan :
o Apakah anda orang yang tepat untuk menjawab pertanyaan ini? Apakah anda resmi?
o Apakah pertanyaan saya relevan dengan problem yang anda punyai?
o Apakah saya terlalu banyak pertanyaan?
o Apakah ada orang lain yang dapat menyedikan informasi tambahan?
o Adakah sesuatu yang lain yang dapat saya tanyakan kepada anda?
Bagian Question dan Answer hanya akan digunakan untuk pertemuan pertama yang kemudian diganti dengan format pertemuan yang mengkombinasikan elemen-elemen penyelesaian masalah, negoisasi, dan spesifikasi. Sejumlah peneliti lepas mengembangkan pedekatan yang berorientasi pada tim terhadap pengumpulan kebutuhan yang dapat deiterapkan untuk membangun ruang lingkup sebuah proyek, yang disebut teknik spesifikasi aplikasi yang teraplikasi (FAST)


4. SUMBER DAYA

Mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak yang meliputi manusia, komponen perangkat lunak, dan peranti perangkat keras/perangkat lunak. Piramida di atas memperlihatkan sumber daya pengembangan sebagai sebuah piramid. Peranti perangkat keras dan perangkat lunak berada pada fondasi dari piramida di atas dan menyediakan infrastruktur untuk mendukung usaha pengembangan(lingkungan pengembang). Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reuseable – blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Dan di puncak terdapat sumber daya utama yaitu manusia. Masing-masing sumber daya ditentukan dengan empat karakteristik :
o Deskripsi sumber daya
o Statemen ketersediaan
o Waktu kronologis sumber daya diperlukan
o Durasi waktu sumber daya diaplikasikan
5.4.1 Sumber daya manusia
Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan. Baik posisi organisasi maupun specialty. Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan setelah estimasi usaha pengembangan dibuat.
5.4.2 Sumber daya perangkat lunak reusable
Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat perencanaan berlangsung, yaitu :
– Komponen off-the-self Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya.
– Komponen full-experience Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini.
– Komponen partial-experience Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial.
– Komponen baru Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek sekarang .Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala dapat terjadi.
5.4.3 Sumber daya lingkungan
Lingkungan yang mendukung poyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh. Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain.
 
5.5 ESTIMASI PROYEK PERANGKAT LUNAK

Biaya perangkat lunak terdiri dari presentase kecil pada biaya sistem berbasis komputer secara keseluruhan. Kesalahan estimasi biaya yang besar dapat memberikan perbedaan antara keuntungan dan kerugian. Estimasi proyek perangkat lunak dapat ditranformasi dari suatu seni yang misterius ke dalam langkah-langkah yang sistematis yang memberikan estimasi dengan risiko yang dapat diterima. Sejumlah pilihan untuk mencapai estimasi biaya dan usaha yang dapat dipertanggung jawabkan :
1. Menunda etimasi sampai akhir proyek
2. Mendasarkan etimasi pada proyek-proyek yang mirip yang sudah pernah dilakukan sebelumnya
3. Menggunakan “teknik dekomposisi” yang relatif sederhana untuk melakukan estimasi biaya dan usaha proyek
4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya perangkat lunak.
Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara potensial berharga. Model berbasis pengalaman(data hitoris) dan berbentuk :
d=f(vi)
di mana d adalah satu dari sejumlah harga estimasi(contoh : usaha, biaya,durasi proyek) dan vi adalah parameter independen yang dipilih (seperti LOC dan FP yang diestimasi). Peranti estimasi otomatis mengimplementasi satu atau lebih teknik dekomposisi atau model empiris. Masing-masing pilihan estimasi biaya perangkat lunak yang dapat dilakukan sama baiknya dengan data hitoris yang digunakan untuk menumbuhkan estimasi.

Pengenalan Rekayasa Perangkat Lunak (RPL)

 Apa itu Rekayasa Perangkat Lunak?


Rekayasa atau teknik merupakan penerapan ilmu dan teknologi untuk menyelesaikan permasalahan manusia. Hal ni diselesaikan lewat pengetahuan, matematika, dan pengalaman praktis yang diterapkan untuk mendesain objek atau proses yang berguna. Para praktisi teknik professional disebut perekayasa.
            
Rekayasa perangkat lunak atau Software engineering dalam bahasa inggris merupakan bidang ilmu yang mempelajari tentang segala aspek perangkat lunak, seperti  cara-cara pengembangan, pemeliharaan , pembuatan, serta manajemen kualitas perangkat lunak.
     
Rekayasa perangkat lunak jugamerupakan disiplin rekayasa dengan perangkat lunak yang dikembangkan. Biasanya proses melibatkan penemuan pada keinginan klien, menyusunnya didalam daftar kebutuhan, merangcang arsitektur yang mampu mendukung semua kebutuhan, perancangan, pengodean, pengujian, dan pengintegrasian bagian yang terpisah, menguju keseluruhan, penyebaran, dan pemeliharaan perangkat lunak.  


1. Konsep Dasar Pada Software Engineering

Software engineering didefinisikan oleh Fritz Bauer sebagai: penerapan dan penggunaan prinsip-prinsip engineering yang baik dalam rangka menghasilkan software yang ekonomis, reliable, dan bekerja secara efisien pada komputer sungguhan. Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
Sementara itu IEEE mendefinisikan software engineering sebagai: Aplikasi yang sistematis, tertata, mampu untuk dikembangkan, dioperasikan, dirawat dan diperbaiki, itulah sebuah aplikasi software engenering.dan mempelajarinya
Komponen Software Engenering :
Komponen adalah pokok bahasan yang sangat menarik jika kita membicarakan masalah reuse. Membangun software yang bersifat reusable akan sangat sulit dikarenakan desain komponen yang tidak baik. Hal ini dapat mengakibatkan komponen yang satu dengan yang lain sulit untuk dipisahkan. Di dalam membangun dan memelihara komponen dibutuhkan kejelasan pengertian dari dan antar komponen. Suatu komponen dapat saja memiliki hubungan external atau ketergantungan antar komponen (komponen dependence). Untuk itu diperlukan sebuah tools yang dapat melihat komponen dependence.
Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari serangkaian tugas:
  • Perencanaan & estimasi proyek
  • Analisis kebutuhan sistem dan software
  • Desain struktur data
  • Arsitektur program dan prosedur algoritma
  • Coding
  • Testing dan pemeliharaan2. Peralatan Software Engineering
Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya :
  • CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hard­ware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.
  • Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang analisis, desain, kode dan testing.
  • Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE
  1. Prosedur Software Engineering
Terdiri dari :
  • urut-urutan di mana metode tersebut diterapkan
  • dokumen
  • laporan-laporan
  • formulir-formulir yang diperlukan
  • mengontrol kualitas software
  • mengkoordinasi perubahan yang terjadi pada software

  2. Tanggung Jawab dan Profesi Etika dalam RPL

- Konfedensialitas
konfidensialitas adalah kewajiban untuk menyimpan informasi yang sifatnya sangat rahasia. Setiap karyawan di dalam perusahaan, terutama yang memiliki akses ke rahasia perusahaan seperti akuntan, bagian operasi, manajer, dan lain lain memiliki konsekuensi untuk tidak membuka rahasia perusahaan kepada khalayak umum. Kewajiban ini tidak hanya dipegang oleh karyawan tersebut selama ia masih bekerja disana, tetapi juga setelah karyawan tersebut tidak bekerja di tempat itu lagi. Sangatlah tidak etis apabila seorang karyawan pindah ke perusahaan baru dengan membawa rahasia perusahaannya yang lama agar ia mendapat gaji yang lebih besar.

- Kompetensi
Kompetensi adalah suatu kemampuan untuk melaksanakan atau melakukan suatu pekerjaan atau tugas yang dilandasi  atas ketrampilan dan pengetahuan serta didukung oleh sikap kerja yang dituntut oleh pekerjaan tersebut .

- Hak property dan intelektual

Hak kekayaan materi semakin terbatas akibat dari tekanan sosial dan budaya yang dilaksanakan sesuai dengan norma-norma sosial, dengan tujuan ke arah manfaat etis. Intelektual properti (IP) masih dinyatakan secara pasti, melalui Trade Related Aspects of Intellectual Property Rights (TRIPS) Agreement, bagian dari WTO / GATT Uruguay Round Agreements, dengan cara yang umum. Kontribusi ini berharap pada penggunaan hak kekayaan intelektual, memberikan perbedaan mendasar dengan hak harta benda, menimbulkan kesempatan untuk berlebihan seperti sewa-mencari kesalahan alokasi yang mungkin telah dibuat dan terus dilakukan, sehingga persepsi ketidakadilan fundamental intelektual hak milik seperti yang dilakukan di luar nilai-nilai sosial, yaitu, dalam secara etika tidak bermanfaat .
 

3. SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan Sistem) 

Pengertian SDLC
SDLC adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya merujuk pada sistem komputer atau informasi. Terdapat 3 jenis metode siklus hidup sistem yang paling banyak digunakan, yakni: siklus hidup sistem tradisional (traditional system life cycle), siklus hidup menggunakan protoyping (life cycle using prototyping), dan siklus hidup sistem orientasi objek (object-oriented system life cycle). SDLC (Software Development Life Cycle) berarti sebuah siklus hidup pemngembangan perangkat lunak yang terdiri dari beberapa tahapan-tahapan yang sangat penting dalam keberadaan perangkat lunak yang dilihat dari segi pengembangannya.

Sejarah SDLC
Siklus Hidup Sistem(SLC)  adalah metodologi yang digunakan untuk menggambarkan proses untuk membangun sistem informasi , dimaksudkan untuk mengembangkan sistem informasi dalam cara yang sangat disengaja, terstruktur dan teratur, mengulangi setiap tahap siklus hidup . Pengembangan sistem siklus hidup, menurut Elliott & Strachan & Radford (2004), “berasal pada tahun 1960, untuk mengembangkan skala besar fungsional sistem bisnis di zaman skala besar konglomerat bisnis . Sistem informasi kegiatan berkisar berat pengolahan data dan angka-angka rutinitas “.
Beberapa kerangka kerja pengembangan sistem telah sebagian didasarkan pada SDLC, seperti analisis sistem terstruktur dan metode desain (SSADM) diproduksi untuk pemerintah Inggris Kantor Pemerintah Commerce pada 1980-an. Sejak saat itu, menurut Elliott (2004), “pendekatan siklus kehidupan tradisional untuk pengembangan sistem telah semakin digantikan dengan alternatif pendekatan dan kerangka kerja, yang berusaha mengatasi beberapa kekurangan yang melekat pada SDLC tradisional”.
SDLC adalah proses yang digunakan oleh analis sistem untuk mengembangkan sistem informasi , termasuk persyaratan, validasi kepemilikan (stakeholder), pelatihan, dan pengguna. Setiap SDLC harus menghasilkan sistem berkualitas tinggi yang memenuhi atau melebihi harapan pelanggan, mencapai selesai dalam waktu dan perkiraan biaya, bekerja secara efektif dan efisien di saat ini dan direncanakan Teknologi Informasi infrastruktur , dan murah untuk mempertahankan dan biaya-efektif untuk meningkatkan. sistem komputer yang kompleks dan sering (terutama dengan munculnya baru-baru arsitektur berorientasi layanan ) link beberapa sistem tradisional berpotensi disediakan oleh vendor perangkat lunak yang berbeda. Untuk mengelola tingkat kompleksitas, sejumlah model SDLC atau metodologi telah diciptakan, seperti “ air terjun ”;” spiral ”;” Agile pengembangan perangkat lunak ”;” prototipe cepat ”;” incremental ”; dan” sinkronisasi dan menstabilkan “.
Model SDLC dapat dijelaskan sepanjang spektrum gesit untuk iteratif untuk berurut. metodologi Agile , seperti XP dan scrum , fokus pada proses ringan yang memungkinkan untuk perubahan yang cepat di sepanjang siklus pengembangan. Iteratif metodologi, seperti kesatuan proses rasional dan dinamis pengembangan sistem metode , fokus pada lingkup proyek terbatas dan memperluas atau memperbaiki produk oleh beberapa iterasi. Sequential atau besar-desain-up-depan (BDUF) model, seperti Air Terjun , fokus pada perencanaan lengkap dan benar untuk membimbing proyek-proyek besar dan risiko untuk hasil yang sukses dan dapat diprediks. Model-model lain, seperti Pembangunan Anamorphic , cenderung fokus pada bentuk pembangunan yang dipandu oleh ruang lingkup proyek dan iterasi pengembangan fitur adaptif.
Dalam manajemen proyek proyek dapat didefinisikan baik dengan siklus hidup proyek (PLC) dan SDLC, selama kegiatan yang sedikit berbeda terjadi. Menurut Taylor (2004) “siklus hidup proyek mencakup semua kegiatan proyek , sedangkan siklus hidup pengembangan sistem berfokus pada produk menyadari persyaratan ”.

Tahapan SDLC

Proses pengembangan sistem melewati beberapa tahapan dari mulai sistem itu direncanakan sampai sistem tersebut diterapkan.
Di dalam System Development Live Cycle (SDLC) terdapat 6 jenis tahapan pekerjaan yang dilakukan oleh analis sistem dan programmer dalam membangun sistem informasi.  Langkah yang digunakan meliputi:
 1. Perencanaan sistem, yaitu  mempelajari konsep sistem dan permasalahan yang hendak diselesaikan. apakah sistem baru tersebut realistis dalam masalah pembiayaan, waktu, serta perbedaan dengan sistem yang ada sekarang.

 2. Analisis system adalah sebuah proses investigasi terhadap sistem yang sedang berjalan dengan tujuan untuk mendapatkan jawaban mengenai pengguna sistem, cara kerja sistem dan waktu penggunaan sistem. Dari proses analisa ini akan didapatkan cara untuk membangun sistem baru.

 3. Desain sistem merupakan proses penentuan cara kerja sistem dalam hal architechture design, interface design, database dan spesifikasi file, dan program design. Hasil dari proses perancangan ini akan didapatkan spesifikasi sistem.

 4. Seleksi sistem yaitu Tahap untuk  memilih perangkat keras & perangkat lunak yang dibutuhkan

 5. Implementasi sistem adalah proses pembangunan dan pengujian sistem, instalasi sistem, dan rencana dukungan sistem.

 6. Pemeliharaan sistem yaitu sistem yang telah diimplemantasikan serta dapat mengikuti perkembangan dan perubahan apapun yang terjadi guna meraih tujuan penggunaannya.


Siklus SDLC dijalankan secara berurutan, mulai dari langkah pertama hingga langkah terakhir. Setiap langkah yang telah selesai harus dikaji ulang, kadang-kadang bersama expert user, terutama dalam langkah spesifikasi kebutuhan dan perancangan sistem untuk memastikan bahwa langkah telah dikerjakan dengan benar dan sesuai harapan. Jika tidak maka langkah tersebut perlu diulangi lagi atau kembali ke langkah sebelumnya.