Anda di halaman 1dari 11

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 Websters 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
1.

Model COCOMO mendefinisikan 3 kelas proyek PL


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. Sumber 2 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

2.
3.
4.

dirasakan
Menggambar konsekuensi risiko
Memperkirakan pengaruh risiko pada proyek dan produk
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.


8.2

Kontrol Kualitas, pemeriksaan, kajian, dan pengujian setiap produk


Jaminan Kualitas, fungsi auditing dan pelaporan manajemen
Biaya Kualitas, semua biaya yang diadakan untuk mengejar kualitas
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

DiSusunoleh
Nama:RIESZACAKRADIANSYAH
NIM:09071001009
Jurusan:SistemKomputer

FAKULTASILMUKOMPUTER
UNIVERSITASSRIWIJAYA
PALEMBANG
2011

Anda mungkin juga menyukai