BAB 1 PRODUK
1.1. Mengembangkan Peran Perangkat Lunak
Saat ini, perangkat lunak memiliki dua peran. Di satu sisi berfungsi sebagai sebuah produk, dan di sisi lain sebagai kendaraan yang mengantarkan sebuah produk. Sebagai produk, perangkat lunak mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak computer
1.2. Perangkat Lunak Perangkat lunak adalah :
1. perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan.
2. struktur data yang memungkinkan program memanipulasi informasi secara proporsional, dan
3. dokumen yang menggambarkan operasi dan kegunaan program. 1.3. Perangkat Lunak : Krisis Di Masa Mendatang
Dalam Webster’s Dictionary kata crisis didefinisikan sebagai titik balik dalam segala hal; waktu yang menentukan atau krusial, keadaan atau kejadian. Tetapi untuk perangkat lunak, sudah tidak ada lagi “titik balik” tidak ada “waktu yang menentukan,” dan yang ada hanya perubahan evolusi yang lambat.
1.4. Mitos Perangkat Lunak
- Mitos manajemen. masalah pengaturan keuangan, menjaga jadwal agar tidak kacau, dan peningkatan kualitas.
- Mitos Pelanggan. Mitos ini membawa ke arah pengharapan yang salah (oleh pelanggan) dan ketidak-puasan pengembang.
BAB 2 PROSES
2.1. Pengembangan Perangkat Lunak – Sebuah Lapisan Teknologi
Metode-metode rekayasa perangkat lunak memberikan teknik untuk membangun perangkat lunak. Metode-metode itu menyangkut serangkaian tugas yang luas yang menyangkut analisis kebutuhan, konstruksi program, desain, pengujian dan pemeliharaan. 2.2. Model-Model Proses Perangkat Lunak
Model proses untuk rekayasa perangkat lunak dipilih berdasarkan sifat aplikasi dan proyeknya, metode dan alat-alat bantu yang akan dipakai, dan kontrol serta penyampaian yang dibutuhkan.
2.3. Model Sekuensial Linier
Model sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan.
2.4. Model Prototipe
Sering seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun input detail.
2.5. Model RAD
(RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Jika kebutuhan dipahami dengan
baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase-fase sbb :
2.6. Model Proses Perangkat Lunak Evolusioner
model proses konkuren akan mendefinisikan aktivitas di dalam dua dimensi : dimensi sistem, dan dimensi komponen. Isu tingkat sistem ditujudengan menggunakan tiga aktivitas : desain, assembly, dan pemakaian.
2.7. Model Formal
Metode formal memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi sistem berbasis komputer dengan menggunakan notasi matematis yang tepat
2.8. Teknik Generasi Keempat
Bentuk “teknik generasi keempat” (4GT) mencakup serangkaian bantu perangkat lunak yang luas yang secara umum memiliki satu hal : masing-masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa karakteristik perangkat lunak pada suatu tingkat yang tinggi.
2.9. Teknologi Proses
teknologi proses untuk membantu organisasi perangkat lunak menganalisa proses mereka yang sedang berlangsung, mengorganisasi tugas-tugas kerja, mengontrol dan memonitor kemajuan, serta mengatur kualitas teknis.
BAB 3 KONSEP MANAJEMEN PROYEK
3.1 Spektrum Manajemen
Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus pada 3 P, dimana harus berurut yaitu PEOPLE, PRODUCK/PROBLEM, PROSES, dan PROYEK.
3.2 People ( Manusia)
SEI telah mengembangkan suatu model kematangan kemampuan manajemen manusia (People Management Capability Manurity Model ( PM – CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi, menyebarkan dan memelihara bakat yang dibutuhkan untuk mengembangkan kemapuan mengembankan PL mereka.
3.3 Problem / Product
Karena informasi yang diberikan customer tidak lengkap. 3.4 Process
Proses PL memberikan suatu kerangka kerja dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan
- Sejumlah kumpulan tugas yang berbeda, kemampuan penyampaian & jaminan kualitas
- Aktifitas pelindung, jaminan kualitas PL, manajemen konfigurasi PL & pengukuran
3.5 Proyek
proyek mengalami kesulitan yaitu 1. Kemajuan mengalami kecacatan
2. Tidak ada cara untuk mengkalibrasi kemajuan karena tidak memperoleh matrik kuantitatif
3. Rencana proyek belum dirancang untuk menakomodasi sumber daya yang diperlukan 4. Resiko-resiko belum mempertimbangkan secara eksplisit serta belum dibuat rencana
untuk mengurangi, mengatur & memonitor 5. Jadual yang ada tidak realistis & cacat
BAB 4 PROSES PERANGKAT LUNAK & METRIK PROYEK
4.1 Pengukuran, Metrik, Dan Indikator
- Measure (mengukur) : Mengindikasikan kuantitatif dari luasan, jumlah, dimensi,
kapasitas, atau ukuran dari atribut sebuah proses atau produk.
- Measurement (pengukuran) : Kegiatan menentukan sebuah measure (pengukuran) - Metrics (metrik) : Ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen,
atau proses memiliki atribut tertentu.
- Indicator (indicator) : Sebuah metrik atau kombinasi dari metrik yg memberikan
pengetahuan kedalam proses PL, sebuah proyek PL. 4.2 Metrik Dalam Proses Dan Domain Proyek
Metrik Proses , Metrik proses digunakan untuk tujuan strategis. Cara untuk meningkatkan proses perangkat lunak :
- Mengukur atribut tertentu dari proses
- Mengembangkan serangkaian metrik yg berarti
- Memberikan indikator yg akan membawa kepada sebuah strategi pengembangan.
Metrik Proyek
Tujuan metrik proyek :
- untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yg diperlukan untuk menghindari penundaan serta mengurangi masalah & resiko potensial.
- untuk memperkirakan kualitas produk pada basis yg berlaku, dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas.
4.3 Pengukuran Perangkat Lunak
Metrik Size-Oriented, Metrik size-oriented tidak diterima sebagai cara terbaik untuk mengukur proses pengembangan perangkat lunak. Sebagian besar berkisar di seputar pemakaian LOC.
Metrik Function-Oriented, Metode pendekatan yg digunakan dapat disebut : Function Point (FP).
BAB 5 PERENCANAAN PROYEK PERANGKAT LUNAK
5.1 Tujuan Perencanaan Proyek Perangkat Lunak
Menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan terhadap sumber daya, biaya dan jadwal pada awal proyek yang dibatasi oleh waktu
5.2 Ruang Lingkup Pl
Ruang lingkup PL menggambarkan : fungsi, kinerja, batasan, interface dan reliabilitas. 5.3 Model COCOMO mendefinisikan 3 kelas proyek PL
1. Model Organik, Ukuran proyek relatif kecil, PL yang dibuat atau dikembangkan lebih simpel dengan aplikasi kerja yg baik.
2. Model Semi Detached, Ukuran proyek dan kekompleksan perangkat cukup besar 3. Model Embedded, Ukuran proyek dan kekompleksan PL yg dikembangkan 5.4 Keputusan Make-Buy
Keputusan make-buy dengan pilihan :
1. PL dapat dibeli (atau lisensi) off-the-self.
2. Komponen PL full-experience dan partial-experience, dapat diperoleh dan kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri.
3. PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.
5.5 Membuat Pohon Keputusan
Rekayasa atau organisasi PL dapat menggunakan teknik statistik analisis pohon keputusan dengan pilihan :
1. Membangun sistem X dari permulaan
2. Menggunakan lagi komponen partial experience yang ada untuk membangun sistem
3. Membeli sebuah produk perangkat lunak yang dapat diperoleh dan dimodifikasi 4. Mengkontrakkan pengembangan PL ke vendor luar
BAB 6 MANAJEMEN RESIKO
6.1 Defenisi Konseptual Mengenai Resiko : (Robert Charette) 1. Resiko berhubungan dengan kejadian di masa yg akan datang.
2. Resiko melibatkan perubahan (spt. perubahan pikiran, pendapat, aksi, atau tempat) 3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan dilakukan. 6.2 Strategi Resiko Reaktif Vs Proaktif
Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber2 daya
dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang sebenarnya /
penting.
Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & pengaruh proyek diperkirakan, dan diprioritaskan menurut kepentingan. 6.3 Komponen Risiko dan Driver
Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu menghendaki agar manajer proyek mengidentifikasi risiko driver yg mempengaruhi komponen risiko PL – kinerja, biaya, dukungan dan jadwal
6.3 Proyeksi Risiko / Perkiraan Risiko Dua cara melakukan proyeksi risiko :
1. Probabilitas di mana risiko adalah nyata
2. Konsekuensi masalah yang berhubungan dengan risiko
Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko :
1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan
2. Menggambar konsekuensi risiko
3. Memperkirakan pengaruh risiko pada proyek dan produk
4. Mencatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalah pahaman
6.4 Menilai Pengaruh Risiko
Tiga factor yg mempengaruhi konsekuensi jika suatu risiko benar-benar terjadi : 1. Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia terjadi 2. Ruang lingkupnya; menggabungkan kepelikannya
3. Timingnya; mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.
6.5 Pengurangan, Monitoring Dan Manajemen Risiko Strategi yg efektif harus dilakukan:
1. Menghindari risiko 2. Memonitoring risiko
3. Manajemen risiko dan perencanaan kemungkinan 6.6 Risiko Keselamatan Dan Bahaya
Risiko tidak hanya pada proyek itu sendiri tetapi juga pada risiko kegagalan PL dilapangan (pemakai akhir).
6.7 RMMM PLAN
Strategi manajemen risiko dapat dimasukkan dalam rencana proyek PL atau langkah manajemen risiko dapat diatur ke dalam RMMM PLAN yg terpisah dimana akan didokumentasikan semua kegiatan yg dilakukan sebagai bagian dari analisis risiko dan oleh manajer proyek digunakan sebagai bagian dari keseluruhan rencana proyek.
BAB 7 PENJADWALAN & PENELUSURAN PROYEK
7.1 Hubungan Antara Manusia Dan Kerja
Waktu untuk mempelajari sistem mengakibatkan meningkatnya jalur komunikasi sehingga membutuhkan kerja tambahan dan tambahan waktu proyek.
7.2 Menentukan Serangkaian Tugas Untuk Proyek
Rangkaian tugas adalah sekumpulan tugas kerja RPL, pondasi, dan kemampuan penyampaian yg harus diselesaikan untuk menyelesaikan sebuah proyek tertentu serta memberikan disiplin yg cukup untuk mencapai kualitas PL yg tinggi.
7. 3 Memilih Tugas Tugas Rpl
Tim perangkat lunak harus memahami apa yg harus dilakukan (ruang llingkup), tim/manajer hrs menentukan apakah ada orang yg dapat mengerjakannya (perencanaan), menentukan risiko
7.4 Penyaringan Tugas-Tugas Mayor
Jadual mikroskopik harus disaring untuk menghasilkan jadual proyek lengkap, penyaringan dimulai dengan mengambil setiap tugas utama & melakukan dekomposisi terhadap tugas tersebut kedlm serangkaian sub tugas .
7.5 Menentukan Jaringan Tugas
Jaringan tugas merupakan repr esentasi grafik dari aliran tugas sebuah proyek & digunakan sebagai mekanisme untuk seluruh rangkaian & ketergantunagn tugas merupakan input bagi suatu alat bantu penjadual proyek secara otomatis.
7.6 Penjadualan
Teknik kajian & evaluasi program (PERT) & metode jalur kritis (CPM) adalah dua metode penjadualan proyek yg dapat diaplikasikan pd pengembangan perangkat lunak.
BAB 8 JAMINAN KUALITAS PERANGKAT LUNAK
8.1 Software Quality Assurance [SQA]
Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak.
- Kontrol Kualitas, pemeriksaan, kajian, dan pengujian setiap produk - Jaminan Kualitas, fungsi auditing dan pelaporan manajemen
- Biaya Kualitas, semua biaya yang diadakan untuk mengejar kualitas
8.2 Jaminan Kualitas Perangkat Lunak
Kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implicit.
8.3 Kajian Perangkat Lunak
Kajian perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi untuk mencari kesalahan yg kemudian akan dihilangkan
8.4 Kajian Teknik Formal (Formal Technic Review - FTR )
Kajian teknik formal atau walktrough adalah pertemuan kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan.
8.5 Jaminan Kualitas Statistik (SQA)
Jaminan kualitas statistik mencerminkan trend yang sedang tumbuh di seluruh industri untuk menjadi lebih kuantitatif terhadap kualitas.
8.6 Pendekatan ISO terhadap Sistem Jaminan Kualitas
Model jaminan kualitas ISO 9000 memperlakukan perusahaan sebagai jaringan proses yang saling terhubung (interkoneksi).
8.7 Standar ISO 9001
TUGAS MERANGKUM
REKAYASA PERANGKAT LUNAK
FAKULTAS ILMU KOMPUTER
UNIVERSITAS SRIWIJAYA
PALEMBANG
Di Susun oleh
Nama : RIESZA CAKRADIANSYAH NIM : 09071001009
