Anda di halaman 1dari 12

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.
- Mitos Para Praktisi. Cara dan kebiasaan lama tetap sukar lenyap.
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


ISO 9001 adalah standar kualitas yang berkalu untuk rekayasa perangkat lunak
TUGAS MERANGKUM
REKAYASA PERANGKAT LUNAK

Di Susun oleh

Nama : RIESZA CAKRADIANSYAH


NIM : 09071001009
Jurusan : Sistem Komputer

FAKULTAS ILMU KOMPUTER

UNIVERSITAS SRIWIJAYA

PALEMBANG
2011

Anda mungkin juga menyukai