Pengertian Manajemen
Dalam mengartikan dan mendefinisikan administrasi ada aneka macam ragam, ada yang mengartikan dengan ketatalaksanaan, manajemen, administrasi pengurusan dan lain se- bagainya. Bila dilihat dari literatur-literatur yang ada, pengertian administrasi sanggup dilihat dari tiga pengertian:
1. administrasi sebagai suatu proses.
2. administrasi sebagai suatu kolektivitas manusia
3. administrasi 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 administrasi sebagai suatu proses sanggup dilihat dari pengertian berdasarkan :
1. Encylopedia of The Social Science, yaitu suatu proses dimana pelaksanaan suatu tujuan tertentu dilaksanakan dan diawasi.
2. Haiman, administrasi 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 kegiatan administrasi disebut manajer.
Manajemen sebagai suatu ilmu dan seni, melihat bagaimana kegiatan administrasi dihubungkan dengan prinsip-prinsip dari manajemen. Pengertian administrasi sebagai suatu ilmu dan seni dari :
1. Chaster I Bernard dalam bukunya yang berjudul JTAe^BnctÃon of the Executive, bahwa administrasi yaitu seni dan ilmu, juga Henry Fajol, Alfin Brown Harold, Koontz Cyril O’donnel dan GerQge K Terry.
2. Marry Parker FoUett menyatakan bahwa administrasi sebagai seni dalam menuntaskan pekerjaan melalui orang lain.
Dari devinisi di atas sanggup ditarik kesimpulan bahwa administrasi 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 yaitu suatu pendekatan terstruktur/metodologi dalam mengelola ketidakpastian yang berkaitan dengan ancaman; suatu rangkaian kegiatan insan termasuk: Penilaian risiko, pengembangan seni administrasi untuk mengelolanya dan mitigasi risiko dengan memakai pemberdayaan/pengelolaan sumberdaya. Strategi yang sanggup diambil antara lain yaitu memindahkan risiko kepada pihak lain, menghindari risiko, mengurangi imbas 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 musibah atau kebakaran, kematian, serta tuntutan hukum. Manajemen risiko keuangan, di sisi lain, terfokus pada risiko yang sanggup dikelola dengan memakai instrumen-instrumen keuangan.
Sasaran dari pelaksanaan administrasi risiko yaitu untuk mengurangi risiko yang berbeda-beda yang berkaitan dengan bidang yang telah dipilih pada tingkat yang sanggup diterima oleh masyarakat. Hal ini sanggup berupa aneka macam jenis ancaman yang disebabkan oleh lingkungan, teknologi, manusia, organisasi dan politik. Di sisi lain pelaksanaan administrasi risiko melibatkan segala cara yang tersedia bagi manusia, khususnya, bagi entitas administrasi risiko (manusia, staff, dan organisasi).
Kegiatan proyek biasanya dilakukan untuk aneka macam bidang antara lain sebagai berikut:
* Perbaikan akomodasi yang sudah ada. Merupakan kelanjutan dan perjuangan yang sudah ada sebelumnya. Artinya sudah ada kegiatan sebelumnya, namun perlu dilakukan komplemen atau perbaikan yang diinginkan
* Pembangunan akomodasi baru. Artinya merupakan kegiatan yang benar-benar gres dan belum pernah ada sebelumnya, sehingga ada penambahan perjuangan baru..
* Penelitian dan pengembangan. Merupakan kegiatan penelitian yang dilakukan untuk suatu fenomena yang muncul di masyarakat, kemudian dikembangkan sedemikian rupa sesuai dengan tujuan yang diharapkan.
Resiko merupakan bentuk keadaan ketidakpastian perihal suatu keadaan yang akan terjadi nantinya (future) dengan keputusan yang diambil berdasarkan aneka macam pertimbangan pada ketika ini. Manajemen resiko yaitu proses pengukuran atau penilaian resiko serta pengembangan seni administrasi 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 bekerjasama 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 duduk kasus yang sesungguhnya / penting. Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & imbas proyek diperkirakan, dan diprioritaskan berdasarkan kepentingan, kemudian membangun suatu planning untuk administrasi resiko. Sasaran utama yaitu 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 sanggup diramalkan
• Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam planning 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) – duduk kasus 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
- duduk kasus 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 sesungguhnya tdk pernah diinginkan oleh setiap orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan seni administrasi bisnis bagi perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah potongan pemasaran tidak tahu bagaimana harus menjualnya.
4. Kehilangan dukungan administrasi senior sehubungan dg perubahan pd fokus atau perubahan pd insan (resiko manajemen)
5. Kehilangan hal2 yg bekerjasama dgn biaya atau janji personal (resiko biaya).
@ Resiko yg sudah diketahui yaitu resiko yg dpt diungkap sesudah dilakukan penilaian secara hati2 terhadap planning proyek, bisnis, & lingkungan teknik dimana proyek sedang dikembangkan, dan sumber isu reliable lainnya.
menyerupai :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg sanggup diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
Misalnya :
- pergantian staf
- komunikasi yg jelek dgn para pelanggan
- mengurangi perjuangan staff bila undangan pemeliharaan
sedang berlangsung dilayani
Rekayasa Perangkat Lunak Bab 6 Halaman 4
@ Resiko yg tidak diharapkan
resiko ini sanggup benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
Identifikasi Resiko Identifikasi resiko dalah perjuangan sistematis untuk memilih ancaman terhadap planning proyek. Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap ketika diperlukan.
Tipe resiko :
1. resiko generic merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik hanya sanggup diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.
Metode untuk mengidentifikasi resiko yaitu membuat checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg menghipnotis 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 bekerjasama dgn ukuran dan pengalaman staf Rekayasa Perangkat Lunak Bab 6 Halaman 5
@ Resiko ukuran produk
Resiko yg bekerjasama dgn keseluruhan ukuran PL yg akan dibangun atau dimodifikasi.
Checklist item resiko yg bekerjasama 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 dibentuk atau dipakai oleh produk ?
• jumlah pemakai produk ?
• jumlah perubahan yg diproyeksikan ke persyaratan produk ? sebelum produk ? sesudah penyampaian ?
• jumlah PL yg dipakai kembali ?
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg kemudian sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg menghipnotis bisnis
Resiko yg bekerjasama dengan batasan yg dibebankan oleh administrasi atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik pribadi dengan kenyataan teknis.
Checklist item resiko yg bekerjasama dgn imbas bisnis :
Rekayasa Perangkat Lunak Bab 6 Halaman 6 Pengaruh produk terhadap hasil perusahaan ?
• Visibilitas produk terhadap administrasi senior ?
• Kelayakan deadline penyampaian ?
• Jumlah pelanggan yg akan memakai produk & konsistensi
• kebutuhan relatif mereka dengan produk tersebut ? Jumlah produk / sistem lain dgn apa produk ini harus sanggup saling dioperasikan ?
• Kepintaran pemakai final ?
• Jumlah dan kualitas dokumentasi produk yg harus diproduksi & disampaikan kepada pelanggan ?
Batasan pemerintahan pada konstruksi produk ?
• Biaya yg bekerjasama dgn penyampaian yg terlambat ?
• Biaya yg bekerjasama dgn produk defektif ?
• Bila ada persentase deviasi yang besar atau jikalau jumlahnya sama, tetapi hasil sebelumnya sangat kurang dari yg diharapkan, maka resiko tinggi.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg bekerjasama dengan kepintaran pelanggan & kemampuan pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan mempunyai kepribadian yg berbeda.
- Pelanggan mempunyai kekerabatan yg bervariasi dgn pemasok.
- Pelanggan juga adakala bertentangan.
Karakteristik pelanggan menghipnotis kemampuan tim PL untuk menuntaskan suatu proyek sempurna waktu & sesuai anggaran.
Rekayasa Perangkat Lunak Bab 6 Halaman 7 Checklist item resiko yg bekerjasama dgn karakteristik pelanggan:
• Pernahkah anda sebelumnya bekerja dengan pelanggan ?
• Apakah pelanggan mempunyai gagasan yg solid mengenai apa yg diperlukannya ? sudahkah pelanggan memakai waktunya untuk menuliskannya ?
• Apakah pelanggan akan oke 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 cendekia dlm area produk tsb?
• Apakah pelanggan bersedia membiarkan orang2 melaksanakan pekerjaan mereka ?
• Apakah pelanggan memahami proses perangkat lunak tsb ?
Bila setiap balasan dari pertanyaan diatas yaitu ‘tidak’, maka pemeriksaan 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 sanggup yg dilakukan, maka proyek tersebut beresiko.
Masalah-masalah proses
• Apakah administrasi senior anda mendukung suatu pernyataan kebijaksanaan yg menekankan pentingnya suatu proses standar untuk pengembangan proses ?
• Sudahkah organisasi anda membuatkan suatu diskripsi tertulis mengenai proses PL yg akan dipakai pd proyek ini ?
Rekayasa Perangkat Lunak Bab 6 Halaman 8
• Apakah anggota2 staf ‘ditugasi’ ke proses PL pd ketika PL didokumentasi & bersedia menggunakannya ?
• Apakah proses PL dipakai untuk proyek lain ?
• Sudahkah organisasi anda membuatkan atau mendapatkan serangkaian serangkaian kursus pembinaan 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 potongan yg sanggup disampaikan sebagai potongan dari proses PL ?
• Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode dilakukan secara reguler ?
• Apakah kajian teknis formal terhadap mekanisme pengujian & test case dilakukan secara reguler ?
• Apakah hasil dari masing2 kajian teknis formal didokumentasikan, termasuk kesalahan yg ditemukan & sumber daya yg dipakai ?
• Apakah mekanisme utk memastikan bahwa kerja yg dilakukan pd suatu proyek sesuai dengan standar RPL ?
• Apakah administrasi konfigurasi dipakai utk memelihara konsistensi diantara _ystem/persyaratan PL, desain, kode, dan test case ?
• Apakah dipakai suatu mekanisme utk mengontrol perubahan ke persyaratan pelanggan yg menghipnotis PL ?
• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan planning pengembangan PL yg didokumentasikan untuk masing2 subkontrak ?
• Apakah ada mekanisme untuk menelusuri & mengkaji kinerja subkontrak ?
Masalah-masalah teknis
Rekayasa Perangkat Lunak Bab 6 Halaman 9
• Apakah dipakai teknik spesifikasi aplikasi untuk membantu komunikasi diantara pelanggan & pengembang ?
• Apakah metode spesifik dipakai 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 & dipakai ?
• Apakah anda memakai metode spesifik utk desain test case?
• Apakah dipakai peranti PL utk mendukung perencanaan & kegiatan penelusuran ?
• Apakah dipakai peranti PL administrasi konfigurasi utk me-ngontrol & menelusuri kegiatan perubahan diseluruh proses PL ?
• Apakah dipakai peranti PL utk mendukung analisis PL & desain proses ?
• Apakah dipakai peranti utk membuat prototipe PL ?
• Apakah dipakai peranti PL utk mendukung proses pengujian ?
• Apakah peranti PL dipakai utk mendukung produksi dan administrasi dokumentasi ?
• Apakah metrik kualitas dikumpulkan bagi semua proyek PL ?
• Apakah metrik produktivitas dikumpulkan bagi semua proyek PL?
Bila lebih banyak didominasi balasan terhadap pertanyaan tsb yaitu `tidak`, maka proses PL lemah dan berisiko tinggi.
@ Resiko teknologi yang akan dibangun
Rekayasa Perangkat Lunak Bab 6 Halaman 10
Resiko yg bekerjasama dgn kompleksitas sistem yg akan dibangun dan `kebaruan` teknologi yg dikemas oleh system. Checklist item resiko yg bekerjasama dengan teknologi yg akan dibangun :
• Apakah teknologi yg akan dibangun yaitu hal yg gres untuk organisasi anda?
• Apakah persyaratan pelanggan memerlukan kreasi algoritma gres atau teknologi input atau output?
• Apakah PL berinterface dgn perangkat keras gres 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 diharapkan interface pemakai khusus oleh persyaratan produk?
• Apakah persyaratan untuk produk memerlukan kreasi komponen jadwal 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 sanggup ’dilakukan’?
Bila balasan dari pertanyaan2 di atas yaitu ’ya’, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Rekayasa Perangkat Lunak Bab 6 Halaman 11
@ Resiko lingkungan pengembangan
Resiko yg bekerjasama dgn keberadaan & kualitas peranti yg akan dipakai untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan produk.
Lingkungan yg salah sanggup menjadi sumber resiko yg penting.
Checklist item resiko yg bekerjasama dengan lingkungan
pengembangan :
• Apakah peranti administrasi proyek sanggup diperoleh?
• Apakah peranti administrasi proses sanggup diperoleh?
• Apakah peranti untuk analisis dan desain sanggup diperoleh?
• Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yg akan dibangun?
• Apakah kompiler atau generasi kode sanggup diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti pengujian sanggup diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti administrasi konfigurasi PL sanggup diperoleh?
• Apakah lingkungan memakai suatu database atau daerah penyimpanan?
• Apakah semua peranti PL sanggup diintegrasikan satu dgn lainnya?
• Sudahkah anggota tim proyek mendapatkan pembinaan dgn masing2 peranti?
• Apakah ada pakar lokal untuk menjawab pertanyaan2 mengenai peranti tersebut?
• Apakah tunjangan dan dokumentasi on-line bagi peranti memadai?
Bila lebih banyak didominasi balasan terhadap pertanyaan tersebut yaitu ’tidak’, berarti lingkungan pengembangan PL lemah dan berisiko tinggi.
Rekayasa Perangkat Lunak Bab 6 Halaman 12
@ Resiko yg bekerjasama dgn ukuran & pengalaman staf
Resiko yg bekerjasama dgn keseluruhan teknik & pengalaman proyek dari RPL yg akan melaksanakan kiprah tsb. Checklist item resiko yg bekerjasama dengan ukuran & pengalaman staf :
• Apakah orang2 terbaik sanggup diperoleh?
• Apakah orang2 tsb mempunyai campuran 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 mempunyai pengharapan yg sempurna mengenai pekerjaan yg ada sekarang?
• Sudahkah staf mendapatkan pembinaan yg memadai?
• Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas?
Bila balasan terhadap pertanyaan2 tsb yaitu ’tidak’, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Komponen Risiko dan Driver Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu
menghendaki supaya manajer proyek mengidentifikasi risiko driver yg menghipnotis 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 gampang dikoreksi, diubahsuaikan dan ditingkatkan.
Manajemen Proyek
Manajemen proyek yaitu cara mengorganisir dan mengelola sumber penghasilan yang penting untuk menuntaskan proyek.
Hal pertama yang harus dianggap sebagai administrasi proyek yaitu bahwa proyek ini diantarkan dengan batasan yang ada. Hal kedua yaitu kemungkinan terbaik distribusi sumber daya. Manajemen proyek yaitu seni mengontrol baik hal selama proyek, dari semenjak dimulai hingga selesai.
Sumber http://ronald-koeman.blogspot.com/
Dalam mengartikan dan mendefinisikan administrasi ada aneka macam ragam, ada yang mengartikan dengan ketatalaksanaan, manajemen, administrasi pengurusan dan lain se- bagainya. Bila dilihat dari literatur-literatur yang ada, pengertian administrasi sanggup dilihat dari tiga pengertian:
1. administrasi sebagai suatu proses.
2. administrasi sebagai suatu kolektivitas manusia
3. administrasi 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 administrasi sebagai suatu proses sanggup dilihat dari pengertian berdasarkan :
1. Encylopedia of The Social Science, yaitu suatu proses dimana pelaksanaan suatu tujuan tertentu dilaksanakan dan diawasi.
2. Haiman, administrasi 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 kegiatan administrasi disebut manajer.
Manajemen sebagai suatu ilmu dan seni, melihat bagaimana kegiatan administrasi dihubungkan dengan prinsip-prinsip dari manajemen. Pengertian administrasi sebagai suatu ilmu dan seni dari :
1. Chaster I Bernard dalam bukunya yang berjudul JTAe^BnctÃon of the Executive, bahwa administrasi yaitu seni dan ilmu, juga Henry Fajol, Alfin Brown Harold, Koontz Cyril O’donnel dan GerQge K Terry.
2. Marry Parker FoUett menyatakan bahwa administrasi sebagai seni dalam menuntaskan pekerjaan melalui orang lain.
Dari devinisi di atas sanggup ditarik kesimpulan bahwa administrasi 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 yaitu suatu pendekatan terstruktur/metodologi dalam mengelola ketidakpastian yang berkaitan dengan ancaman; suatu rangkaian kegiatan insan termasuk: Penilaian risiko, pengembangan seni administrasi untuk mengelolanya dan mitigasi risiko dengan memakai pemberdayaan/pengelolaan sumberdaya. Strategi yang sanggup diambil antara lain yaitu memindahkan risiko kepada pihak lain, menghindari risiko, mengurangi imbas 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 musibah atau kebakaran, kematian, serta tuntutan hukum. Manajemen risiko keuangan, di sisi lain, terfokus pada risiko yang sanggup dikelola dengan memakai instrumen-instrumen keuangan.
Sasaran dari pelaksanaan administrasi risiko yaitu untuk mengurangi risiko yang berbeda-beda yang berkaitan dengan bidang yang telah dipilih pada tingkat yang sanggup diterima oleh masyarakat. Hal ini sanggup berupa aneka macam jenis ancaman yang disebabkan oleh lingkungan, teknologi, manusia, organisasi dan politik. Di sisi lain pelaksanaan administrasi risiko melibatkan segala cara yang tersedia bagi manusia, khususnya, bagi entitas administrasi risiko (manusia, staff, dan organisasi).
Kegiatan proyek biasanya dilakukan untuk aneka macam bidang antara lain sebagai berikut:
* Perbaikan akomodasi yang sudah ada. Merupakan kelanjutan dan perjuangan yang sudah ada sebelumnya. Artinya sudah ada kegiatan sebelumnya, namun perlu dilakukan komplemen atau perbaikan yang diinginkan
* Pembangunan akomodasi baru. Artinya merupakan kegiatan yang benar-benar gres dan belum pernah ada sebelumnya, sehingga ada penambahan perjuangan baru..
* Penelitian dan pengembangan. Merupakan kegiatan penelitian yang dilakukan untuk suatu fenomena yang muncul di masyarakat, kemudian dikembangkan sedemikian rupa sesuai dengan tujuan yang diharapkan.
Resiko merupakan bentuk keadaan ketidakpastian perihal suatu keadaan yang akan terjadi nantinya (future) dengan keputusan yang diambil berdasarkan aneka macam pertimbangan pada ketika ini. Manajemen resiko yaitu proses pengukuran atau penilaian resiko serta pengembangan seni administrasi 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 bekerjasama 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 duduk kasus yang sesungguhnya / penting. Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & imbas proyek diperkirakan, dan diprioritaskan berdasarkan kepentingan, kemudian membangun suatu planning untuk administrasi resiko. Sasaran utama yaitu 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 sanggup diramalkan
• Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam planning 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) – duduk kasus 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
- duduk kasus 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 sesungguhnya tdk pernah diinginkan oleh setiap orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan seni administrasi bisnis bagi perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah potongan pemasaran tidak tahu bagaimana harus menjualnya.
4. Kehilangan dukungan administrasi senior sehubungan dg perubahan pd fokus atau perubahan pd insan (resiko manajemen)
5. Kehilangan hal2 yg bekerjasama dgn biaya atau janji personal (resiko biaya).
@ Resiko yg sudah diketahui yaitu resiko yg dpt diungkap sesudah dilakukan penilaian secara hati2 terhadap planning proyek, bisnis, & lingkungan teknik dimana proyek sedang dikembangkan, dan sumber isu reliable lainnya.
menyerupai :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg sanggup diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
Misalnya :
- pergantian staf
- komunikasi yg jelek dgn para pelanggan
- mengurangi perjuangan staff bila undangan pemeliharaan
sedang berlangsung dilayani
Rekayasa Perangkat Lunak Bab 6 Halaman 4
@ Resiko yg tidak diharapkan
resiko ini sanggup benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
Identifikasi Resiko Identifikasi resiko dalah perjuangan sistematis untuk memilih ancaman terhadap planning proyek. Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap ketika diperlukan.
Tipe resiko :
1. resiko generic merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik hanya sanggup diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.
Metode untuk mengidentifikasi resiko yaitu membuat checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg menghipnotis 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 bekerjasama dgn ukuran dan pengalaman staf Rekayasa Perangkat Lunak Bab 6 Halaman 5
@ Resiko ukuran produk
Resiko yg bekerjasama dgn keseluruhan ukuran PL yg akan dibangun atau dimodifikasi.
Checklist item resiko yg bekerjasama 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 dibentuk atau dipakai oleh produk ?
• jumlah pemakai produk ?
• jumlah perubahan yg diproyeksikan ke persyaratan produk ? sebelum produk ? sesudah penyampaian ?
• jumlah PL yg dipakai kembali ?
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg kemudian sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg menghipnotis bisnis
Resiko yg bekerjasama dengan batasan yg dibebankan oleh administrasi atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik pribadi dengan kenyataan teknis.
Checklist item resiko yg bekerjasama dgn imbas bisnis :
Rekayasa Perangkat Lunak Bab 6 Halaman 6 Pengaruh produk terhadap hasil perusahaan ?
• Visibilitas produk terhadap administrasi senior ?
• Kelayakan deadline penyampaian ?
• Jumlah pelanggan yg akan memakai produk & konsistensi
• kebutuhan relatif mereka dengan produk tersebut ? Jumlah produk / sistem lain dgn apa produk ini harus sanggup saling dioperasikan ?
• Kepintaran pemakai final ?
• Jumlah dan kualitas dokumentasi produk yg harus diproduksi & disampaikan kepada pelanggan ?
Batasan pemerintahan pada konstruksi produk ?
• Biaya yg bekerjasama dgn penyampaian yg terlambat ?
• Biaya yg bekerjasama dgn produk defektif ?
• Bila ada persentase deviasi yang besar atau jikalau jumlahnya sama, tetapi hasil sebelumnya sangat kurang dari yg diharapkan, maka resiko tinggi.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg bekerjasama dengan kepintaran pelanggan & kemampuan pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan mempunyai kepribadian yg berbeda.
- Pelanggan mempunyai kekerabatan yg bervariasi dgn pemasok.
- Pelanggan juga adakala bertentangan.
Karakteristik pelanggan menghipnotis kemampuan tim PL untuk menuntaskan suatu proyek sempurna waktu & sesuai anggaran.
Rekayasa Perangkat Lunak Bab 6 Halaman 7 Checklist item resiko yg bekerjasama dgn karakteristik pelanggan:
• Pernahkah anda sebelumnya bekerja dengan pelanggan ?
• Apakah pelanggan mempunyai gagasan yg solid mengenai apa yg diperlukannya ? sudahkah pelanggan memakai waktunya untuk menuliskannya ?
• Apakah pelanggan akan oke 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 cendekia dlm area produk tsb?
• Apakah pelanggan bersedia membiarkan orang2 melaksanakan pekerjaan mereka ?
• Apakah pelanggan memahami proses perangkat lunak tsb ?
Bila setiap balasan dari pertanyaan diatas yaitu ‘tidak’, maka pemeriksaan 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 sanggup yg dilakukan, maka proyek tersebut beresiko.
Masalah-masalah proses
• Apakah administrasi senior anda mendukung suatu pernyataan kebijaksanaan yg menekankan pentingnya suatu proses standar untuk pengembangan proses ?
• Sudahkah organisasi anda membuatkan suatu diskripsi tertulis mengenai proses PL yg akan dipakai pd proyek ini ?
Rekayasa Perangkat Lunak Bab 6 Halaman 8
• Apakah anggota2 staf ‘ditugasi’ ke proses PL pd ketika PL didokumentasi & bersedia menggunakannya ?
• Apakah proses PL dipakai untuk proyek lain ?
• Sudahkah organisasi anda membuatkan atau mendapatkan serangkaian serangkaian kursus pembinaan 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 potongan yg sanggup disampaikan sebagai potongan dari proses PL ?
• Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode dilakukan secara reguler ?
• Apakah kajian teknis formal terhadap mekanisme pengujian & test case dilakukan secara reguler ?
• Apakah hasil dari masing2 kajian teknis formal didokumentasikan, termasuk kesalahan yg ditemukan & sumber daya yg dipakai ?
• Apakah mekanisme utk memastikan bahwa kerja yg dilakukan pd suatu proyek sesuai dengan standar RPL ?
• Apakah administrasi konfigurasi dipakai utk memelihara konsistensi diantara _ystem/persyaratan PL, desain, kode, dan test case ?
• Apakah dipakai suatu mekanisme utk mengontrol perubahan ke persyaratan pelanggan yg menghipnotis PL ?
• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan planning pengembangan PL yg didokumentasikan untuk masing2 subkontrak ?
• Apakah ada mekanisme untuk menelusuri & mengkaji kinerja subkontrak ?
Masalah-masalah teknis
Rekayasa Perangkat Lunak Bab 6 Halaman 9
• Apakah dipakai teknik spesifikasi aplikasi untuk membantu komunikasi diantara pelanggan & pengembang ?
• Apakah metode spesifik dipakai 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 & dipakai ?
• Apakah anda memakai metode spesifik utk desain test case?
• Apakah dipakai peranti PL utk mendukung perencanaan & kegiatan penelusuran ?
• Apakah dipakai peranti PL administrasi konfigurasi utk me-ngontrol & menelusuri kegiatan perubahan diseluruh proses PL ?
• Apakah dipakai peranti PL utk mendukung analisis PL & desain proses ?
• Apakah dipakai peranti utk membuat prototipe PL ?
• Apakah dipakai peranti PL utk mendukung proses pengujian ?
• Apakah peranti PL dipakai utk mendukung produksi dan administrasi dokumentasi ?
• Apakah metrik kualitas dikumpulkan bagi semua proyek PL ?
• Apakah metrik produktivitas dikumpulkan bagi semua proyek PL?
Bila lebih banyak didominasi balasan terhadap pertanyaan tsb yaitu `tidak`, maka proses PL lemah dan berisiko tinggi.
@ Resiko teknologi yang akan dibangun
Rekayasa Perangkat Lunak Bab 6 Halaman 10
Resiko yg bekerjasama dgn kompleksitas sistem yg akan dibangun dan `kebaruan` teknologi yg dikemas oleh system. Checklist item resiko yg bekerjasama dengan teknologi yg akan dibangun :
• Apakah teknologi yg akan dibangun yaitu hal yg gres untuk organisasi anda?
• Apakah persyaratan pelanggan memerlukan kreasi algoritma gres atau teknologi input atau output?
• Apakah PL berinterface dgn perangkat keras gres 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 diharapkan interface pemakai khusus oleh persyaratan produk?
• Apakah persyaratan untuk produk memerlukan kreasi komponen jadwal 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 sanggup ’dilakukan’?
Bila balasan dari pertanyaan2 di atas yaitu ’ya’, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Rekayasa Perangkat Lunak Bab 6 Halaman 11
@ Resiko lingkungan pengembangan
Resiko yg bekerjasama dgn keberadaan & kualitas peranti yg akan dipakai untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan produk.
Lingkungan yg salah sanggup menjadi sumber resiko yg penting.
Checklist item resiko yg bekerjasama dengan lingkungan
pengembangan :
• Apakah peranti administrasi proyek sanggup diperoleh?
• Apakah peranti administrasi proses sanggup diperoleh?
• Apakah peranti untuk analisis dan desain sanggup diperoleh?
• Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yg akan dibangun?
• Apakah kompiler atau generasi kode sanggup diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti pengujian sanggup diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti administrasi konfigurasi PL sanggup diperoleh?
• Apakah lingkungan memakai suatu database atau daerah penyimpanan?
• Apakah semua peranti PL sanggup diintegrasikan satu dgn lainnya?
• Sudahkah anggota tim proyek mendapatkan pembinaan dgn masing2 peranti?
• Apakah ada pakar lokal untuk menjawab pertanyaan2 mengenai peranti tersebut?
• Apakah tunjangan dan dokumentasi on-line bagi peranti memadai?
Bila lebih banyak didominasi balasan terhadap pertanyaan tersebut yaitu ’tidak’, berarti lingkungan pengembangan PL lemah dan berisiko tinggi.
Rekayasa Perangkat Lunak Bab 6 Halaman 12
@ Resiko yg bekerjasama dgn ukuran & pengalaman staf
Resiko yg bekerjasama dgn keseluruhan teknik & pengalaman proyek dari RPL yg akan melaksanakan kiprah tsb. Checklist item resiko yg bekerjasama dengan ukuran & pengalaman staf :
• Apakah orang2 terbaik sanggup diperoleh?
• Apakah orang2 tsb mempunyai campuran 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 mempunyai pengharapan yg sempurna mengenai pekerjaan yg ada sekarang?
• Sudahkah staf mendapatkan pembinaan yg memadai?
• Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas?
Bila balasan terhadap pertanyaan2 tsb yaitu ’tidak’, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Komponen Risiko dan Driver Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu
menghendaki supaya manajer proyek mengidentifikasi risiko driver yg menghipnotis 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 gampang dikoreksi, diubahsuaikan dan ditingkatkan.
Manajemen Proyek
Manajemen proyek yaitu cara mengorganisir dan mengelola sumber penghasilan yang penting untuk menuntaskan proyek.
Hal pertama yang harus dianggap sebagai administrasi proyek yaitu bahwa proyek ini diantarkan dengan batasan yang ada. Hal kedua yaitu kemungkinan terbaik distribusi sumber daya. Manajemen proyek yaitu seni mengontrol baik hal selama proyek, dari semenjak dimulai hingga selesai.