Pengertian Manajemen
Dalam mengartikan dan mendefinisikan manajemen ada berbagai ragam, ada yang mengartikan dengan ketatalaksanaan, manajemen, manajemen pengurusan dan lain se- bagainya. Bila dilihat dari literatur-literatur yang ada, pengertian manajemen dapat dilihat dari tiga pengertian:
1. manajemen sebagai suatu proses.
2. manajemen sebagai suatu kolektivitas manusia
3. manajemen sebagai ilmu (science) dan sebagai seni (art).
Manajemen sebagai suatu proses, melihat bagai mana cara orang untuk mencapai suatu tujuan yang telah ditetapkan terlebih dahulu. Pengertian manajemen sebagai suatu proses dapat dilihat dari pengertian menurut :
1. Encylopedia of The Social Science, yaitu suatu proses dimana pelaksanaan suatu tujuan tertentu dilaksanakan dan diawasi.
2. Haiman, manajemen yaitu fungsi untuk mencapai suatu tujuan melalui kegiatan orang lain, mengawasi usaha-usaha yang dilakukan individu untuk mencapai tujuan.
3. Georçv R. Terry, yaitu cara pencapaian tujuan yang telah ditentukan terlebih dahulu dengan melalui kegiatan orang lain.
Manajemen suatu kolektivitas yaitu merupakan suatu kumpulan dari orang-orang yang bekerja sama untuk mencapai suatu tujuan bersama. Kolektivitas atau kumpulan orang-orang inilah yang disebut dengan manajemen, sedang orang yang bertanggung jawab terhadap terlaksananya suatu tujuan atau berjalannya aktivitas manajemen disebut manajer.
Manajemen sebagai suatu ilmu dan seni, melihat bagaimana aktivitas manajemen dihubungkan dengan prinsip-prinsip dari manajemen. Pengertian manajemen sebagai suatu ilmu dan seni dari :
1. Chaster I Bernard dalam bukunya yang berjudul JTAe^Bnctíon of the Executive, bahwa manajemen yaitu seni dan ilmu, juga Henry Fajol, Alfin Brown Harold, Koontz Cyril O’donnel dan GerQge K Terry.
2. Marry Parker FoUett menyatakan bahwa manajemen sebagai seni dalam menyelesaikan pekerjaan melalui orang lain.
Dari devinisi di atas dapat ditarik kesimpulan bahwa manajemen yaitu koordinasi semua sumber daya melalui proses perencanaan, pengorganisasian, penetapan tenaga kerja, pengarahan dan pengawasan untuk mencapai tujuan yang telah ditetapkan terlebih dahulu
Manajemen Risiko
Manajemen risiko adalah suatu pendekatan terstruktur/metodologi dalam mengelola ketidakpastian yang berkaitan dengan ancaman; suatu rangkaian aktivitas manusia termasuk: Penilaian risiko, pengembangan strategi untuk mengelolanya dan mitigasi risiko dengan menggunakan pemberdayaan/pengelolaan sumberdaya. Strategi yang dapat diambil antara lain adalah memindahkan risiko kepada pihak lain, menghindari risiko, mengurangi efek negatif risiko, dan menampung sebagian atau semua konsekuensi risiko tertentu. Manajemen risiko tradisional terfokus pada risiko-risiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian, serta tuntutan hukum. Manajemen risiko keuangan, di sisi lain, terfokus pada risiko yang dapat dikelola dengan menggunakan instrumen-instrumen keuangan.
Sasaran dari pelaksanaan manajemen risiko adalah untuk mengurangi risiko yang berbeda-beda yang berkaitan dengan bidang yang telah dipilih pada tingkat yang dapat diterima oleh masyarakat. Hal ini dapat berupa berbagai jenis ancaman yang disebabkan oleh lingkungan, teknologi, manusia, organisasi dan politik. Di sisi lain pelaksanaan manajemen risiko melibatkan segala cara yang tersedia bagi manusia, khususnya, bagi entitas manajemen risiko (manusia, staff, dan organisasi).
Kegiatan proyek biasanya dilakukan untuk berbagai bidang antara lain sebagai berikut:
* Perbaikan fasilitas yang sudah ada. Merupakan kelanjutan dan usaha yang sudah ada sebelumnya. Artinya sudah ada kegiatan sebelumnya, namun perlu dilakukan tambahan atau perbaikan yang diinginkan
* Pembangunan fasilitas baru. Artinya merupakan kegiatan yang benar-benar baru dan belum pernah ada sebelumnya, sehingga ada penambahan usaha baru..
* Penelitian dan pengembangan. Merupakan kegiatan penelitian yang dilakukan untuk suatu fenomena yang muncul di masyarakat, lalu dikembangkan sedemikian rupa sesuai dengan tujuan yang diharapkan.
Resiko merupakan bentuk keadaan ketidakpastian tentang suatu keadaan yang akan terjadi nantinya (future) dengan keputusan yang diambil berdasarkan berbagai pertimbangan pada saat ini. Manajemen resiko adalah proses pengukuran atau penilaian resiko serta pengembangan strategi pengelolaannya.
Jenis Resiko Teknologi :
- Komponen file tidak lengkap
- Sistem operasi tidak kompatibel, device tidak dikenal
- Perangkat keras tidak mendukung (mis: resolusi monitor, resolusi printer)
- Spesifikasi tidak memenuhi
- Kualitas Network dibawah standar kebutuhan
- Browser, software tidak memenuhi
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.
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, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko.
Resiko Perangkat Lunak
Karakteristik resiko :
1. Ketidakpastian
2. Kerugian
Kategori resiko :
• Resiko proyek
• Resiko teknis
• Resiko bisnis
Rekayasa Perangkat Lunak Bab 6 Halaman 2
Kategori resiko oleh Robert Charette :
• Resiko yang sudah diketahui
• Resiko yang dapat diramalkan
• Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip & biaya menjadi bertambah. Resiko proyek mengidenifikasi :
- biaya – sumber daya
- jadwal – pelanggan
- personil (staffing & organisasi) – masalah persyaratan
@ Resiko teknis
Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit atau tidak mungkin.
Resiko teknis mengidentifikasi :
- desain potensial – ambiquitas
- implementasi – spesifikasi
- interfacing – ketidakpastian teknik
- verivikasi – keusangan teknik
- masalah pemeliharaan – teknologi yg leading edge
@ Resiko bisnis
Resiko bisnis mengancam viabilitas PL yg akan dibangun. Resiko bisnis membahayakan proyek atau produk.
Rekayasa Perangkat Lunak Bab 6 Halaman 3
resiko bisnis utama :
1. pembangunan produk atau sistem yg baik sebenarnya tdk pernah diinginkan oleh setiap orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan strategi bisnis bagi perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu bagaimana harus menjualnya.
4. Kehilangan dukungan manajemen senior sehubungan dg perubahan pd fokus atau perubahan pd manusia (resiko manajemen)
5. Kehilangan hal2 yg berhubungan dgn biaya atau komitmen personal (resiko biaya).
@ Resiko yg sudah diketahui adalah resiko yg dpt diungkap setelah dilakukan evaluasi secara hati2 terhadap rencana proyek, bisnis, & lingkungan teknik dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya.
seperti :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
Misalnya :
- pergantian staf
- komunikasi yg buruk dgn para pelanggan
- mengurangi usaha staff bila permintaan pemeliharaan
sedang berlangsung dilayani
Rekayasa Perangkat Lunak Bab 6 Halaman 4
@ Resiko yg tidak diharapkan
resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
Identifikasi Resiko Identifikasi resiko dalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.
Tipe resiko :
1. resiko generic merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik hanya dapat diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg mempengaruhi bisnis
o resiko yg dihubungkan dgn karakteristik pelanggan
o resiko definisi proses
o resiko teknologi yang akan dibangun
o resiko lingkungan pengembangan
o resiko yg berhubungan dgn ukuran dan pengalaman staf Rekayasa Perangkat Lunak Bab 6 Halaman 5
@ Resiko ukuran produk
Resiko yg berhubungan dgn keseluruhan ukuran PL yg akan dibangun atau dimodifikasi.
Checklist item resiko yg berhubungan dgn ukuran produk (PL) :
• ukuran produk diperkirakan dalam LOC atau FP ?
• tingkat kepercayaan dlm estimasi ukuran yg diperkirakan ?
• ukuran produk yg diestimasi dalam jumlah program, file, transaksi ?
• presentase deviasi dalam ukuran produk dari rata2 produk terakhir ?
• ukuran database yg dibuat atau digunakan oleh produk ?
• jumlah pemakai produk ?
• jumlah perubahan yg diproyeksikan ke persyaratan produk ? sebelum produk ? setelah penyampaian ?
• jumlah PL yg digunakan kembali ?
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg lalu sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis
Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik langsung dengan kenyataan teknis.
Checklist item resiko yg berhubungan dgn pengaruh bisnis :
Rekayasa Perangkat Lunak Bab 6 Halaman 6 Pengaruh produk terhadap hasil perusahaan ?
• Visibilitas produk terhadap manajemen senior ?
• Kelayakan deadline penyampaian ?
• Jumlah pelanggan yg akan menggunakan produk & konsistensi
• kebutuhan relatif mereka dengan produk tersebut ? Jumlah produk / sistem lain dgn apa produk ini harus dapat saling dioperasikan ?
• Kepintaran pemakai akhir ?
• Jumlah dan kualitas dokumentasi produk yg harus diproduksi & disampaikan kepada pelanggan ?
Batasan pemerintahan pada konstruksi produk ?
• Biaya yg berhubungan dgn penyampaian yg terlambat ?
• Biaya yg berhubungan dgn produk defektif ?
• Bila ada persentase deviasi yang besar atau jika jumlahnya sama, tetapi hasil sebelumnya sangat kurang dari yg diharapkan, maka resiko tinggi.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg berhubungan dengan kepintaran pelanggan & kemampuan pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan memiliki kepribadian yg berbeda.
- Pelanggan memiliki hubungan yg bervariasi dgn pemasok.
- Pelanggan juga kadang-kadang bertentangan.
Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk menyelesaikan suatu proyek tepat waktu & sesuai anggaran.
Rekayasa Perangkat Lunak Bab 6 Halaman 7 Checklist item resiko yg berhubungan dgn karakteristik pelanggan:
• Pernahkah anda sebelumnya bekerja dengan pelanggan ?
• Apakah pelanggan memiliki gagasan yg solid mengenai apa yg diperlukannya ? sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
• Apakah pelanggan akan setuju dgn penggunaan waktu didalam pertemuan pengumpulan persyaratan formal (bab 11) utk mengidentifikasi ruang lingkup proyek ?
• Apakah pelanggan bersedia membangun sambungan komunikasi cepat dgn pengembang ?
• Apakah pelanggan bersedia berpartisipasi dalam kajian ?
• Apakah pelanggan secara teknis pandai dlm area produk tsb?
• Apakah pelanggan bersedia membiarkan orang2 melakukan pekerjaan mereka ?
• Apakah pelanggan memahami proses perangkat lunak tsb ?
Bila setiap jawaban dari pertanyaan diatas adalah ‘tidak’, maka investigasi lebih jauh harus dilakukan utk memperkirakan potensi resiko.
@ Resiko definisi proses
Bila kualitas merupakan sebuah konsep yg disetujui sbg hal yg penting tetapi tidak tidak ada yg berintdak untuk mencapainya dengan cara yg dapat yg dilakukan, maka proyek tersebut beresiko.
Masalah-masalah proses
• Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yg menekankan pentingnya suatu proses standar untuk pengembangan proses ?
• Sudahkah organisasi anda mengembangkan suatu diskripsi tertulis mengenai proses PL yg akan digunakan pd proyek ini ?
Rekayasa Perangkat Lunak Bab 6 Halaman 8
• Apakah anggota2 staf ‘ditugasi’ ke proses PL pd saat PL didokumentasi & bersedia menggunakannya ?
• Apakah proses PL digunakan untuk proyek lain ?
• Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian serangkaian kursus pelatihan RPL bagi para manajer dan staf teknik ?
• Apakah standar RPL yg diterbitkan disediakan utk setiap pengembang PL & manajer PL ?
• Sudahkah dokumen outline & contoh2 dikembangkan untuk semua yg ditentukan sebagai bagian yg dapat disampaikan sebagai bagian dari proses PL ?
• Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode dilakukan secara reguler ?
• Apakah kajian teknis formal terhadap prosedur pengujian & test case dilakukan secara reguler ?
• Apakah hasil dari masing2 kajian teknis formal didokumentasikan, termasuk kesalahan yg ditemukan & sumber daya yg digunakan ?
• Apakah mekanisme utk memastikan bahwa kerja yg dilakukan pd suatu proyek sesuai dengan standar RPL ?
• Apakah manajemen konfigurasi digunakan utk memelihara konsistensi diantara _ystem/persyaratan PL, desain, kode, dan test case ?
• Apakah digunakan suatu mekanisme utk mengontrol perubahan ke persyaratan pelanggan yg mempengaruhi PL ?
• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan rencana pengembangan PL yg didokumentasikan untuk masing2 subkontrak ?
• Apakah ada prosedur untuk menelusuri & mengkaji kinerja subkontrak ?
Masalah-masalah teknis
Rekayasa Perangkat Lunak Bab 6 Halaman 9
• Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi diantara pelanggan & pengembang ?
• Apakah metode spesifik digunakan untuk analisis PL ?
• Apakah anda melihat suatu metode spesifik untuk data & desain arsitektur ?
• Apakah lebih dari 90% dari kode anda ditulis dgn bahasa orde yg lebih tinggi ?
• Apakah konvensi spesifik utk dokumentasi kode didefinisikan & digunakan ?
• Apakah anda menggunakan metode spesifik utk desain test case?
• Apakah digunakan peranti PL utk mendukung perencanaan & aktivitas penelusuran ?
• Apakah digunakan peranti PL manajemen konfigurasi utk me-ngontrol & menelusuri aktivitas perubahan diseluruh proses PL ?
• Apakah digunakan peranti PL utk mendukung analisis PL & desain proses ?
• Apakah digunakan peranti utk menciptakan prototipe PL ?
• Apakah digunakan peranti PL utk mendukung proses pengujian ?
• Apakah peranti PL digunakan utk mendukung produksi dan manajemen dokumentasi ?
• Apakah metrik kualitas dikumpulkan bagi semua proyek PL ?
• Apakah metrik produktivitas dikumpulkan bagi semua proyek PL?
Bila mayoritas jawaban terhadap pertanyaan tsb adalah `tidak`, maka proses PL lemah dan berisiko tinggi.
@ Resiko teknologi yang akan dibangun
Rekayasa Perangkat Lunak Bab 6 Halaman 10
Resiko yg berhubungan dgn kompleksitas sistem yg akan dibangun dan `kebaruan` teknologi yg dikemas oleh system. Checklist item resiko yg berhubungan dengan teknologi yg akan dibangun :
• Apakah teknologi yg akan dibangun adalah hal yg baru untuk organisasi anda?
• Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output?
• Apakah PL berinterface dgn perangkat keras baru atau belum terbukti?
• Apakah PL yg akan dibangun ber-interace dgn produk PL yg dipasok oleh vendor yg belum terbukti?
• Apakah PL yg akan dibangun ber-interface dgn suatu system database yg fungsi kinerjanya belum dibuktikan di dalam area aplikasi ini?
• Apakan diperlukan interface pemakai khusus oleh persyaratan produk?
• Apakah persyaratan untuk produk memerlukan kreasi komponen program yg tidak sama dengan yg dikembangkan terakhir oleh organisasi anda?
• Apakah persyarata memerlukan pemakaian analisis, desain atau metode pengujian baru?
• Apakah persyaratan memerlukan metode pengembangan PL tdk konvensional, spt metode formal, pendekatan Al-based dan jaringan syaraf buatan?
• Apakah persyaratan meletakkan batasan kinerja yg eksesif pada produk tersebut?
• Apakah pelanggan tidak yakin pada fungsionalitas yg diminta dapat ’dilakukan’?
Bila jawaban dari pertanyaan2 di atas adalah ’ya’, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Rekayasa Perangkat Lunak Bab 6 Halaman 11
@ Resiko lingkungan pengembangan
Resiko yg berhubungan dgn keberadaan & kualitas peranti yg akan digunakan untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan produk.
Lingkungan yg salah dapat menjadi sumber resiko yg penting.
Checklist item resiko yg berhubungan dengan lingkungan
pengembangan :
• Apakah peranti manajemen proyek dapat diperoleh?
• Apakah peranti manajemen proses dapat diperoleh?
• Apakah peranti untuk analisis dan desain dapat diperoleh?
• Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yg akan dibangun?
• Apakah kompiler atau generasi kode dapat diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti manajemen konfigurasi PL dapat diperoleh?
• Apakah lingkungan menggunakan suatu database atau tempat penyimpanan?
• Apakah semua peranti PL dapat diintegrasikan satu dgn lainnya?
• Sudahkah anggota tim proyek menerima pelatihan dgn masing2 peranti?
• Apakah ada pakar lokal untuk menjawab pertanyaan2 mengenai peranti tersebut?
• Apakah bantuan dan dokumentasi on-line bagi peranti memadai?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti lingkungan pengembangan PL lemah dan berisiko tinggi.
Rekayasa Perangkat Lunak Bab 6 Halaman 12
@ Resiko yg berhubungan dgn ukuran & pengalaman staf
Resiko yg berhubungan dgn keseluruhan teknik & pengalaman proyek dari RPL yg akan melakukan tugas tsb. Checklist item resiko yg berhubungan dengan ukuran & pengalaman staf :
• Apakah orang2 terbaik dapat diperoleh?
• Apakah orang2 tsb memiliki gabungan ketrampilan yg benar?
• Apakah orang2 yg ada mencukupi?
• Apakah staf dimasukkan ke dalam seluruh durasi proyek?
• Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini?
• Apaka staf memiliki pengharapan yg tepat mengenai pekerjaan yg ada sekarang?
• Sudahkah staf menerima pelatihan yg memadai?
• Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas?
Bila jawaban terhadap pertanyaan2 tsb adalah ’tidak’, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
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.
Komponen risiko didefinisikan dgn cara sbb :
Rekayasa Perangkat Lunak Bab 6 Halaman 13
• Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya.
• Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga
• Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan.
Manajemen Proyek
Manajemen proyek adalah cara mengorganisir dan mengelola sumber penghasilan yang penting untuk menyelesaikan proyek.
Hal pertama yang harus dianggap sebagai manajemen proyek adalah bahwa proyek ini diantarkan dengan batasan yang ada. Hal kedua adalah kemungkinan terbaik distribusi sumber daya. Manajemen proyek adalah seni mengontrol baik hal selama proyek, dari sejak dimulai sampai selesai.
