Magang Kerja

Kali ini saya dianjurkan untuk melakukan magang kerja yang sesuai dengan jurusan manajeman keuangan , saya membuat surat keterangan yang telah disediakan oleh studentsite saya mengajukan banyak tempat magang ada kira-kira sekitar 8 tempat magang yang saya ajukan hmmm banyak tantangan yang saya lewati saat saya mengajukan magang kerja , banyak pengalaman yang saya dapat pula saat mencari tempat magang ternyata mencari tempat magang tidak semudah yang saya bayangkan , banyak perusahaan yang tidak memberikan jawaban saya dibolehkan magang atau tidaknya , akhirnya saya pun putus asa karena teman-teman saya telah mendapatkan tempat magang . terakhir saya mengajukan dikantor pelayanan pajak pratama jakarta duren sawit dengan harapan tipis sekali karena menunggu jawabannya pun agak sedikit lama sekitar 2 minggu akhirnya jawaban dari kantor pusatpun dtng saya diterima magang disana saya meminta ditempatkan dibagian penagihan dengan judul yang saya ambil tentang penagihan pajak, semua pegawainya ramah dan friendly sm anak-anak yang magang disini. banyak pelajaran yang saya ambil dalam magang kerja dikantor pelayanan pajak pratama ini :) thanks kpp pratama jakarta duren sawit :)

• Project Factor

Merupakan hal yang penting bahwa pengembangan dan obyektifnya terdefinisi dengan baik dan diketahui secara jelas oleh semua anggota tim dan semua stakeholder utama. Jika hal ini tidak terlaksana dapat muncul resiko yang berkaitan dengan keberhasilan pengembangan tersebut. Dengan cara serupa, perencanaan kualitas yang formal dan telah disepakati harus dipahami oleh semua partisipan.  Jika perencanaan kualitas kurang baik dan tidak tersosialisasi maka  dapat mengakibatkan gangguan pada pengembangan tersebut.

• Project Methods

Dengan mempergunakan spefikasi dan metode terstruktur yang baik pada manajemen pengembangan dan pengembangan sistem akan mengurangi resiko penyerahan sistem yang tidak memuaskan atau terlambat. Akan tetapi penggunaan metode tersebut untuk pertama kali dapat mengakibatkan problem dan delay.

• Hardware/software Factor

Sebuah pengembangan yang memerlukan hardware baru untuk pengembangan mempunyai resiko yang lebih tinggi dibandingkan dengan software yang dapat dibangun pada hardware  yang sudah ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu jenis hardware atau software platform tertentu jika dipergunakan pada hardware atau software platform lainnya bisa menimbulkan resiko tambahan (dan tinggi) pada saat instalasi.

• Changeover Factor

Kebutuhan perubahan “all-in-one” kedalam suatu sistem baru mempunyai resiko tertentu. Perubahan secara bertahap atau gradual akan meminimisasi resiko akan tetapi cara tersebut tidak praktis. Menjalankan secara paralel dapat memberikan solusi yang aman akan tetapi biasanya tidak mungkin atau terlalu mahal.

• Supplier Factor

Suatu pengembangan yang melibatkan organisasi eksternal yang tidak dapat dikendalikan secara langsung dapat mempengaruhi keberhasilan pengembangan.  Misal tertundanya  instalasi jalur telpon atau pengiriman peralatan yang sulit dihindari- dapat berpengaruh terhadap keberhasilan pengembangan.

• Environment Factor

Perubahan pada lingkungan dapat mempengaruhi keberhasilan pengembangan. Misal terjadi perubahan regulasi pajak, akan mempunyai dampak yang cukup serius pada pengembangan aplikasi penggajian.

• Health and Safety Factor

Ada satu isu utama yaitu faktor kesehatan dan keamanan dari partisipan yang terlibat dalam pengembangan software walaupun tidak umum (dibandingkan dengan pengembangan teknik sipil) yang dapat mempengaruhi aktifitas pengembangan.

Kesalahan estimasi

Beberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan tersebut. Pembuatan sebuah user manual merupakan langkah yang tepat yang dapat dipertanggungjawabkan dan sebagai bukti bahwa kita pernah mengerjakan tugas yang serupa sebelumnya. Dengan pengalaman itu seharusnya kita mampu untuk melakukan estimasi dengan lebih tepat mengenai berapa lama pekerjaan dapat diselesaikan dan berapa besarnya biaya yang dibutuhkan. Selain itu, waktu yang dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa walaupun kita pernah membuat program yang serupa sebelumnya.

Estimasi dapat ditingkatkan melalui analisa data historis untuk aktifitas yang serupa dan untuk sistem yang serupa. Dengan menyimpan perbandingan antara estimasi semula dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat.

Resiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.

Asumsi perencanaan

Pada setiap tahapan perencanaan, asumsi perlu dibuat, jika tidak benar maka dapat mengakibatkan resiko tersebut beresiko. Misal pada jaringan aktifitas, aktifitas dibangun berdasarkan pada asumsi menggunakan metode desain tertentu dimana memungkinkan urutan aktifitas diubah. Kita biasanya membuat asumsi bahwa setelah coding, biasanya sebuah modul akan diuji dan kemudian diintegrasikan dengan modul lainnya. Akan tetapi kita tidak merencanakan pengujian modul yang dapat mangakibatkan perubahan desain awal. Hal ini dapat terjadi setiap saat.

Pada setiap tahapan pada proses perencanaan, sangat penting untuk memeperinci secara eksplisit semua asumsi yang dibuat dan mengidentifikasi apa pengaruhnya jika ternyata dalam pelaksanaannya tidak sesuai dengan yang sudah direncanakan.

Kemungkinan

Beberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat menyakinkan diri kita sendiri bahwa ada sesuatu yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. Akan tetapi biasanya jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan biasanya dapat diidentifikasi beberapa spesifikasi kebutuhan kemungkinan diubah setelah beberapa modul telah dikodekan, programmer senior meninggalkan pengembangan, perangkat keras yang diperlukan tidak dikirim tapat waktu. Beberapa kejadian semacam itu dapat terjadi sewaktu-waktu dan walaupun kejadian tersebut kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut perlu dipertimbangkan dan direncanakan.

Metode untuk evaluasi pengaruh ketidakpastian ini terhadap jadwal proyek:

• Penggunaan PERT untuk evaluasi pengaruh ketidakpastian

PERT dikembangkan untuk menghitung estimasi ketidakpastian lingkungan terhadap durasi pekerjaan. PERT dikembangkan pada suatu lingkungan proyek yang mahal, beresiko tinggi dan kompleks. Metode PERT ini memerlukan tiga estimasi:

-      Most likely time

              Waktu yang diperlukan untuk menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m.

-      Optimistic time

              Waktu tersingkat yang diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a.

-      Pessimistic time

              Waktu terlama yang diperlukan untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal dan diberikan simbol b.

PERT mengkombinasikan ketiga estimasi tersebut untuk membentuk durasi tunggal yang diharapkan, t_e = a + 4m + b

• Penggunaan durasi yang diharapkan

Durasi yang diharapkan dipergunakan supaya suatu forward pass dapat melalui sebuah jaringan; dengan mempergunakan metode yang sama dengan teknik CPM. Akan tetapi dalam hal ini, tanggal aktifitas yang dihitung bukan merupakan tanggal paling awal akan tetapi merupakan tanggal yang diharapkan dapat mencapai aktifitas tersebut. 

Jaringan PERT yang diperlihatkan pada gambar 3 memperlihatkan bahwa kita berharap proyek tersebut dapat diselesaikan dalam waktu 13,5 minggu- tidak seperti CPM yang tidak memperlihatkan tanggal paling awal untuk menyelesaikan proyek tersebut akan tetapi tanggal yang diharapkan (atau most likely). Salah satu keuntungan dari pendekatan ini adalah menempatkan sebuah emphasis dalam ketidakpastian di dunia nyata. 

Tabel 6.3 berikut ini memperlihatkan contoh estimasi durasi aktifitas yang memperkirakan durasi secara optimistic(a), pessimistic(b) dan most likeliy(m).

MANAJEMEN RESIKO

          Manajemen resiko adalah proses pengukuran atau penilaian resiko serta pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu. Manajemen resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta tuntutan hokum). (Wikipedia)

          Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian (Roger S. Pressman).

Pada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan resiko tersebut.

          Mengapa manajemen resiko itu penting? Sikap orang ketika menghadapi resiko berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap resiko ini dapat membantu untuk mengerti betapa resiko itu penting untuk ditangani dengan baik.

Beberapa resiko lebih penting dibandingkan resiko lainnya. Baik penting maupun tidak sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya pada aktifitas tertentu dan kekritisan aktifitas tersebut. Aktifitas beresiko tinggi pada jalur kritis pengembangan biasanya merupakan penyebabnya.

          Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko atau paling tidak mendistribusikannya selama pengembangan tersebut dan idealnya resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang kritis.

          Resiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung pada siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi resiko dan alokasi staf dan sumber daya lainnya erat kaitannya.

Resiko dalam perangkat lunak memiliki dua karakteristik:

-      Uncertainty : tidak ada resiko yang 100% pasti muncul.

-      Loss : resiko berimbas pada kehilangan.

Dan resiko memiliki tiga kategori:

-      Resiko proyek : berefek pada perencanaan proyek.

-      Resiko teknikal : berefek pada kualitas dan waktu pembuatan perangkat lunak.

-      Resiko bisnis : berefek pada nilai jual produk

Contoh : Seorang programmer yang sangat pintar keluar. Resiko yang mana?

Langkah-langkah dalam manajemen proses adalah :

1. Identifikasi resiko

Proses ini meliputi identifikasi resiko yang mungkin terjadi dalam suatu aktivitas usaha. Identifikasi resiko secara akurat dan komplit sangatlah vital dalam manajemen resiko. Salah satu aspek penting dalam identifikasi resiko adalah mendaftar resiko yang mungkin terjadi sebanyak mungkin. Teknik-teknik yang dapat digunakan dalam identifikasi resiko antara lain:

• Brainstorming
• Survei
• Wawancara
• Informasi histori
• Kelompok kerja

Tipe-tipe resiko:

Untuk keperluan identifikasi dan mengelola resiko yang dapat menyebabkan sebuah pengembangan melampaui batas waktu dan biaya yang sudah dialokasikan maka perlu diidentifikasikan tiga tipe resiko yang ada yaitu:

• Resiko yang disebabkan karena kesulitan melakukan estimasi.
• Resiko yang disebabkan karena asumsi yang dibuat selama proses perencanaan.
• Resiko yang disebabkan adanya even yang tidak terlihat (atau tidak direncanakan).

Beberapa kategori faktor yang perlu dipertimbangkan adalah sebagai berikut:

• Application Factor

Sesuatu yang alami dari aplikasi baik aplikasi pengolahan data yang sederhana, sebuah sistem kritis yang aman maupun sistem terdistribusi yang besar dengan elemen real time terlihat menjadi sebuah faktor kritis. Ukuran yang diharapkan dari aplikasi juga sesuatu yang penting – sistem  yang lebih besar, lebih besar dari masalah error, komunikasi dan manajemennya.

• Staff Factor

Pengalaman dan kemampuan staf yang terlibat merupakan faktor utama – seorang programer yang berpengalaman, diharapkan akan sedikit melakukan kesalahan dibandingkan dengan programer yang sedikit pengalamannya. Akan tetapi kita harus juga mempertimbangkan ketepatan pengalaman tersebut- pengalaman membuat modul dengan Cobol bisa mempunyai nilai kecil jika kita akan mengembangkan sistem kendali real-time yang komplek dengan mempergunakan C++.

 Beberapa faktor seperti tingkat kepuasan staf dan tingkat pergantian dari staf juga penting untuk keberhasilan sebarang pengembangan – staf yang tidak termotivasi atau person utama keluar dapat menyebabkan kegagalan pengembangan.