Perancangan Manajemen Proyek Sistem Informasi (Pertemuan 1)

Nama               : Nurul Khabibah

Kelas               : 12.4A.35 MI

Mata Kuliah    : Perancangan Manajemen Proyek Sistem Informasi (Pertemuan 1)

Macam-Macam Metodologi Manajemen Proyek

1.    Metodologi The Traditional Approach

Pendekatan Klasik (classical approach) disebut juga dengan Pendekatan Tradisional (traditional approach) atau Pendekatan Konvensional (conventional approach). Metodologi Pendekatan Klasik mengembangkan sistem dengan mengikuti tahapan-tahapan pada System Life Cycle. Pendekatan ini menekankan bahwa pengembangan akan berhasil bila mengikuti tahapan pada System Life Cycle.

Permasalahan-permasalahan yang dapat timbul pada Pendekatan Klasik adalah sebagai berikut :

A.  Pengembangan perangkat lunak akan menjadi sulit.

Pendekatan klasik kurang memberikan alat-alat dan teknik-teknik di dalam mengembangkan sistem dan sebagai akibatnya proses pengembangan perangkat lunak menjadi tidak terarah dan sulit untuk dikerjakan oleh pemrogram. Lain halnya dengan pendekatan terstruktur yang memberikan alat-alat seperti diagram arus data (data flow diagram), kamus data (data dictionary), tabel keputusan (decision table). Diagram IPO, bagan terstruktur (structured chart) dan lain sebagainya yang memungkinkan Pengembangan Sistem Informasi pengembangan perangkat lunak lebih terarah berdasarkan alat-alat dan teknik-teknik tersebut.

B.  Biaya perawatan atau pemeliharaan sistem akan menjadi mahal.

Mahalnya biaya perawatan pada pendekatan sistem klasik disebabkan karena dokumentasi sistem yang dikembangkan kurang lengkap dan kurang terstruktur. Dokumentasi ini merupakan hasil dari alat-alat dan teknik-teknik yang digunakan. Karena pendekatan klasik kurang didukung oleh alat-alat dan teknik-teknik, maka dokumentasi menjadi tidak lengkap dan walaupun ada tetapi strukturnya kurang jelas, sehingga pada waktu pemeliharaan sistem menjadi kesulitan.

C.  Kemungkinan kesalahan sistem besar.

Pendekatan klasik tidak menyediakan kepada analis sistem cara untuk melakukan pengetesan sistem, sehingga kemungkinan kesalahan-kesalahan sistem akan menjadi lebih besar.

D.  Keberhasilan sistem kurang terjamin.

Penekanan dari pendekatan klasik adalah kerja dari personil-personil pengembang sistem, bukan pada pemakai sistem, padahal sekarang sudah disadari bahwa dukungan dan pemahaman dari pemakai sistem terhadap sistem yang sedang dikembangkan merupakan hal yang vital untuk keberhasilan proyek pengembangan sistem pada akhirnya.

2.    Metodologi The Rational Unifed Process

RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.

2.1    Sejarah

RUP merupakan produk proses perangkat lunak yang awalnya dikembangkan oleh Rational Software. Rational Software diakuisisi oleh IBM pada Februari 2003. Produk ini memuat basis-pengetahuan yang bertautan dengan artefak sederhana disertai deskripsi detail dari beragam aktivitas. RUP dimasukkan dalam produk IBM Rational Method Composer (RMC) yang memungkinkan untuk kustomisasi proses.

Dengan mengombinasikan pengalaman dari banyak perusahaan, dihasilkan enam praktik terbaik untuk rekayasa perangkat lunak modern:

1. Pengembangan iteratif, dengan risiko sebagai pemicu iterasi primer
2. Kelola persyaratan
3. Terapkan arsitektur yang berbasis komponen
4. Visualisasikan model perangkat lunak
5. Secara kontinyu, verifikasi kualitas
6. Kendalikan perubahan

RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu:

§  Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition.

§  Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, how dan when. Dimensi ini terdiri atas Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment.

Gambar  Arsitektur Rational Unified Process

Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (object orinted) memiliki manfaat yakni:

• Improve productivity

Standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas.

• Deliver high quality system

Kualitas sistem informasi dapat ditingkatkan sebagai sistem yang dibuat pada komponen­komponen yang telah teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery sistem informasi yang dibuat dengan kualitas yang tinggi.

• Lower maintenance cost

Standard ini dapat membantu untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard yang jelas.

• Facilitate reuse

Standard ini memiliki kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.

• Manage complexity

Standard ini mudah untuk mengatur dan memonitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua manajer proyek IT/IS yakni deliver good quality software within cost and schedule time and the users accepted.

2.2    Empat Fasa Siklus Proyek

Pada RUP didefinisikan terdapat empat fasa siklus proyek. Fasa-fasa ini memungkinkan untuk disajikan dalam bentuk umum mirip dengan pendekatan air terjun, walaupun esensi kunci dari proses terdapat dalam iterasi dalam setiap fasenya. Setiap fase memiliki sebuah objektif kunci dan titik pencapaian akhir yang menandakan ketercapaian objektif. Visualisasi dari fase RUP berikut dengan sumbu waktu dinamakan sebagai grafik RUP.

A.  Fasa Insepsi

Objektif primer adalah untuk membatasi sistem dengan cukup sebagai dasar untuk memvalidasi biaya awal dan penganggaran. Pada fasa ini, ditentukan kasus bisnis yaitu: konteks bisnis, faktor sukses (perkiraan pendapatan, pengenalan ke pasar, dll.), dan perkiraan finansial. Sebagai pelengkap kasus bisnis adalah model penggunaan, perencaan proyek, penilaian risiko tahap awal, dan deskripsi proyek disusun.

B.  Fasa Elaborasi

Objektif primer adalah untuk memitigasi risiko kunci yang diidentifikasi dari analisis hingga akhir fase. Fasa elaborasi merupakan fase saat proyek mulai terlihat bentuknya. Pada fase ini, masalah analisis domain dibuat dan arsitektur proyek mulai mendapatkan bentuk dasarnya.

C.  Fasa Konstruksi

Objektif primer adalah untuk membangun sistem perangkat lunak. Fase ini fokus pada pengembangan komponen dan fitur lain dari sistem. Pada fase inilah saat banyak dilakukan pengkodean. Pada proyek yang lebih besar, beberapa iterasi konstruksi dikembangkan sebagai usaha untuk memecah kasus penggunaan menjadi segmen terkelola yang menunjukkan purwarupa.

D.  Fasa Transisi

Objektif primer adalah sebagai perantara sistem dari pengembangan ke produksi, yang tersedia untuk pengguna akhir. Aktivitas dalam fase ini termasuk pelatihan kepada pengguna akhir dan pengelola sistem dan pengujian beta untuk memvalidasi terhadap harapan pengguna akhir.

3.    Metodologi Critical Chain

Critical Chain Project Management (CCPM) merupakan metode pemodelandan analisis manajemen proyek sebagai perpaduan antara berbagai sistem yang ada termasuk di dalamnya manajemen proyek tradisional. Terdapat beberapa konsep dalam Critical Chain Project Management (CCPM):

A.  Estimasi

 Konsep ini menyatakan bahwa dalam mengambil keputusan, seseorang melakukan perkiraan terhadap faktor-faktor yang mungkin berpengaruh terhadap pelaksanaan yang meliputi juga faktor lingkungan tempat dimana seseorang bekerja.

B.  Student Syndrome

Konsep student syndrome menyatakan bahwa seseorang biasanya baru akan memulai menyelesaikan tugas pada waktu mendekati batas akhir pada berapapun waktu yang diberikan.

C.  Parkinson's Law

 Konsep ini menyatakan bahwa orang cenderung melambatkan pekerjaan ketika melihat bahwa ternyata ia memiliki kelebihan waktu atau sebaliknya meningkatkan usaha agar terlihat sibuk selama jadwal tugas.

D.  Multi Tasking

 Konsep ini menyatakan bahwa dalam lingkungan yang terdiri dari berbagai pekerjaan memungkinkan pekerja diminta untuk menghentikan suatu pekerjaan yang belum selesai untuk berganti mengerjakan pekerjaan yang lain dan demikian seterusnya kemudian

kembali lagi memulai pekerjaan yang sama untuk melanjutkan penyelesainnya sehingga orang kehilangan orientasi dan prioritas.

E.   No Early Finishes

 Konsep ini menyatakan bahwa biasanya dalam penyelesaian tugas orang cenderung tepat waktu atau terlambat dan jarang sekali terjadi yang lebih cepat dari jadwal.

F.   Penjadwalan Selambat Mungkin (As Late As Possible Scheduling (ALAP)

Konsep ini menyatakan bahwa tugas-tugas dijadwalkan selambat mungkin dari tanggal penyelsaian proyek dan menempatkan kerja sedekat mungkin dengan jadwal akhir.

           Disinilah Rantai Manajemen Proyek Kritis (CCPM) dapat membantu proyek manager, dengan perencanaan dan pengelolaan jadwal proyek melalui proses optimasi unik yang bergabung dengan tugas-tergantung jalur kritis dengan rantai-kritis sumber daya tergantung tugas yang mempengaruhi proyek tanggal penyelesaian. Rantai kritis eksplisit mendenisikan sumber daya diratakan set tugas . Jika kuantitas sumber daya terbatas, jalur kritis dan rantai kritis adalah identik. Sayangnya, aktivitas sumber daya-leveling yang mengidentikasi rantai kritis sering meluas tanggal akhir proyek.Untuk memenuhi tanggal, akhir asli standar, jadwal baru harus dioptimalkan.

 Optimasi rantai kritis, seperti optimasi jalur kritis, melihat tugas individu untuk menentukan perkiraan waktu dapat dipersingkat. Optimasi rantai kritis, bagaimanapun juga berfokus pada sumber daya proyek, menjaga mereka dengan datar dimuat melalui waktu mulai eksibel dan cepat beralih di antara tugas-tugas. Mengoptimalkan rantai kritis mengakui bahwa marjin keselamatan seluruh awalnya dibangun ke dalam setiap jadwal proyek mungkin tidak diperlukan dan bahwa semua tugas, secara teori, dapat diselesaikan lebih cepat dari jadwal. Perlu diingat, meskipun, bahwa selama margin keselamatan yang ada di tugas individu, kemampuan untuk memperpendek panjang keseluruhan proyek ini diminimalisasi. Namun, jika margin keselamatan semua dihapus dan bahkan satu tugas penting melebihi estimasi panjang, tanggal penyelesaian untuk seluruh proyek terancam pada tingkat tinggi, proses CCPM untuk mengembangkan dan mengendalikan jadwal proyek terdiri dari langkah-langkah berikut:

1.    Mengurangi tugas individual memperkirakan secara dramatis. Hal ini dilakukan baik dengan pemotongan perkiraan sebesar 50 persen atau dengan menerapkan proses tiga titik memperkirakan untuk setiap tugas.

2.    Sumber daya tingkat proyek untuk menghilangkan perselisihan sumber daya. Pada titik ini, jalur kritis di transformasikan ke dalam rantai kritis.

3.    Agregat sebagian dari perkiraan tugas berkurang menjadi penyangga proyek, dan masukkan buer ini pada akhir proyek.

4.    Masukkan makan buer pada titik-titik di mana non-kritis jalur rantai memotong rantai kritis. Subordinasi non-kritis jalur rantai memungkinkan terus fokus pada rantai kritis.

5.    Masukkan buer sumber daya mana yang tepat untuk mengurangi kemungkinan bahwa sumber daya yang penting tidak tersedia ketika dijadwalkan.

6.    Masukkan buer kapasitas mana yang sesuai.

7.    Membatasi atau menghilangkan multitasking.

8.    Jadwal tugas tanpa pendahulu untuk memulai selambat mungkin. Mendorong tugas yang harus diselesaikan secepat mungkin.

9.    Tekankan pentingnya waktu mulai dan penyelesaian tugas agresif daripada tanggal jatuh tempo.

10.    Kelola buer untuk mendukung tindakan preventif dan korektif.

             Meskipun CCPM konsep yang sering diterapkan dalam lingkungan-proyek tunggal, mereka mengambil makna tambahan dalam lingkungan proyek. Sumber daya yang paling dimuat bersama seluruh proyek, juga disebut dengan sumber daya, mempengaruhi tanggal penyelesaian keseluruhan atau jadwal dari masing-masing proyek karena proyek masing-masing dipaksa untuk kemajuan pada kecepatan sumber daya drum. Akibatnya, rantai kritis

dan jalur yang menggabungkan dengan itu mungkin akibat dari ketergantungan sumber daya di luar lingkup sebuah proyek tunggal. Menyediakan visibilitas sumber daya yang ada di luar proyek individu diperlukan untuk mendapatkan gambaran yang benar dari lingkungan manajemen proyek secara keseluruhan dalam organisasi apapun. Jika organisasi Anda sangat

jaringan, memiliki sejumlah besar proyek-proyek yang membutuhkan sumber daya kritis atau beberapa sumber daya drum, dan terutama beroperasi dengan menggunakan waktu sebagai kaki dominan dari kendala tiga, maka CCPM dapat menjadi tambahan berarti untuk Anda proyek manajemen toolkit .

              Tapi setiap organisasi, terlepas dari ukuran dan kecenderungan manajemen proyek, harus mempertimbangkan secara bertahap memasukkan ke dalam metodologi manajemen proyek saat ini prinsip-prinsip CCPM individu yang berlaku. CCPM mungkin pendekatan baru yang paling penting untuk proyek penjadwalan dalam tiga puluh tahun terakhir. Ini adalah metode yang dapat diterapkan untuk memenuhi pernah-semakin agresif persyaratan jadwal bahwa setiap manajer proyek yang dihadapi sementara, pada saat yang sama, membantu organisasi untuk menjaga kualitas dan produktivitas. Telah terbukti menjadi metode yang efektif untuk melindungi proyek-proyek Anda dari slippages tak terelakkan yang terjadi dalam setiap proyek.

Referensi :

[1] B. Santosa. 1997.Manajemen Proyek. Yogyakarta: Graha Ilmu.

[2] A. Husen. 2009. Manajemen Proyek.,Yogyakarta: CV.Anddi Offset.

[3] I. Dispohusodo. 1996. Manajemen Proyek dan Konstruksi. Yogyakarta: Kanisius.

[4] B. Santosa.2009.Manajemen Proyek. Yogyakarta: Graha Ilmu.