- ) Metodologi The Traditional ApproachPendekatan Klasik (classical approach) disebut juga dengan Pendekatan Tradisional (traditional approach) atau Pendekatan Konvensional (conventional approach). Metodologi Pendekatan Tradisional 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 Tradisional adalah sebagai berikut :1. 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 perangkat lunak lebih terarah berdasarkan alat-alat dan teknik-teknik tersebut.2. 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.3. 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.4. 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.Mulai awal tahun 1970 muncul suatu pendekatan baru disebut dengan Pendekatan Terstruktur. Pendekatan ini pada dasarnya mencoba menyediakan kepada analis sistem dengan alat-alat dan teknik-teknik untuk mengembangkan sistem disamping tetap mengikuti ide dari system life cycle.Pendekatan terstruktur (Structured Approach)
Pendekatan terstruktur dilengkapi dengan alat-alat (tools) dan teknik-teknik yang dibutuhkan dalam pengembangan sistem, sehingga hasil akhir dari sistem yang dikembangkan akan didapatkan sistem yang strukturnya didefinisikan dengan baik dan jelas. Beberapa metodologi pengembangan sistem yang terstruktur telah banyak yang diperkenalkan baik dalam buku-buku, maupun oleh perusahaan-perusahaan konsultan pengembang sistem. Metodologi ini memperkenalkan penggunaan alat-alat dan teknik-teknik untuk mengembangkan sistem yang terstruktur. Konsep pengembangan sistem terstruktur bukan merupakan konsep yang baru. Teknik perakitan di pabrik-pabrik dan perancangan sirkuit untuk alat-alat elektronik adalah dua contoh baru konsep ini yang banyak digunakan di industri-industri. Konsep ini memang relatif masih baru digunakan dalam mengembangkan sistem informasi untuk dihasilkan produk sistem yang memuaskan pemakainya. Melalui pendekatan terstruktur, permasalahan-permasalahan yang kompleks dalam organisasi dapat dipecahkan dan hasil dari sistem akan mudah untuk dipelihara, fleksibel, lebih memuaskan pemakainya, mempunyai dokumentasi yang baik, tepat pada waktunya, sesuai dengan anggaran biayanya, dapat meningkatkan produktivitas dan kualitasnya akan lebih baik (bebas kesalahan).Dari Bawah Ke Atas (Bottom-up Approach)
Pendekatan ini dimulai dari level bawah organisasi, yaitu level operasional dimana transaksi dilakukan. Pendekatan ini dimulai dari perumusan kebutuhan-kebutuhan untuk menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan informasi berdasarkan transaksi tersebut. Pendekatan ini ciri-ciri dari pendekatan klasik. Pendekatan dari bawah ke atas bila digunakan pada tahap analisis sistem disebut juga dengan istilah data analysis, karena yang menjadi tekanan adalah data yang akan diolah terlebih dahulu, informasi yang akan dihasilkan menyusul mengikuti datanya.Pendekatan Dari Atas Ke Bawah (Top-down Approach)
Pendekatan Dari Atas Ke Bawah (Top-down Approach) dimulai dari level atas organisasi, yaitu level perencanaan strategi. Pendekatan ini dimulai dengan mendefinisikan sasaran dan kebijaksanaan organisasi. Langkah selanjutnya dari pendekatan ini adalah dilakukannya analisis kebutuhan informasi. Setelah kebutuhan informasi ditentukan, maka proses turun ke pemrosesan transaksi, yaitu penentuan output, input, basis data, prosedur-prosedur operasi dan kontrol. Pendekatan ini juga merupakan ciri-ciri pendekatan terstruktur. Pendekatan atas-turun bila digunakan pada tahap analis sistem disebut juga dengan istilah decision analysis, karena yang menjadi tekanan adalah informasi yang dibutuhkan untuk pengambilan keputusan oleh manajemen terlebih dahulu, kemudian data yang perlu diolah didefinisikan menyusul mengikuti informasi yang dibutuhkan.
2 .Metodologi RUP (Rational Unified Process)
Pengertian Manajemen Proyek
Definisi dari manajemen proyek yaitu penerapan ilmu pengetahuan, keahlian dan ketrampilan, cara teknis yang terbaik dan dengan sumber daya yang terbatas untuk mencapai sasaran yang telah ditentukan agar mendapatkan hasil yang optimal dalam hal kinerja, waktu, mutu dan keselamatan kerja.
Dalam manajemen proyek, perlunya pengelolaan yang baik dan terarah karena suatu proyek memiliki keterbatasan sehingga tujuan akhir dari suatu proyek bisa tercapai. Yang perlu dikekola dalam manajemne proyek yaitu biaya, mutu, waktu, kesehatan dan keselamatan kerja, sumber daya, lingkungan, resiko dan sistem informasi.
Didalam perkembangan teknologi komputer akan kebutuhan manusia yang semakin pesat membuat para pembuat software membuat sebuah perangkat lunak yang bisa memudahkan para penggunanya. Dilatarbelakangi dengan perkembangan teknologi itu maka diciptakan perangkat lunak dengan berorientasi objek. Salah satunya adalah Rational Unified Process.
Metodologi Rational Unified Process (RUP) dalam Manajemen Proyek
RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iterative yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003.
RUP didasarkan pada satu set blok bangunan, atau elemen konten, menggambarkan apa yang harus diproduksi, ketrampilan yang diperlukan dan langkah demi langkah penjelasan menggambarkan bagaimana sasaran-sasaran pembangunan yang spesifik dapat dicapai. Blok bangunan utama, atau elemen konten, adalah sebagai berikut :
- Peran (yang) – Sebuah peran mendefinisikan satu set ketrampilan yang terkait, kompetensi, dan tanggung jawab.
- Work Produk (apa) – Sebuah Kerja Produk merepresentasikan sesuatu yang dihasilkan dari sebuah tugas, termasuk semua dokumen dan model-model yang dihasilkan saat bekerja melalui proses.
- Tugas (bagaimana) – Sebuah Tugas menggambarkan suatu unit kerja yang ditetapkan ke peran yang memberikan hasil bermakna.
Dalam setiap iterasi, tugas-tugas dikelompokkan menjadi Sembilan disiplin: enam “disiplin rekayasa” (Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment) dan tiga mendukung disiplin (Konfigurasi dan Change Management, Project Management, Lingkungan).
- Empat fase siklus hidup proyek
RUP telah menetapkan siklus proyek terdiri dari empat fase. Fase-fase ini memungkinakan proses yang harus dipresentasikan pada tingkat yang tinggi dalam cara yang mirip dengan bagaimana sebuah ‘proyek gaya waterfall’ mungkin disajikan, walaupun pada dasarnya kunci untuk proses iterasi terletak pada pembangunan yang terletak dalam semua fase. Selain itu, setiap fase memiliki satu tujuan utama dan tonggak penting di akhir menunjukkan bahwa tujuan yang dicapai.
Adapun keempat fase tersebut adalah:
- Inception/insepsi
- Elaboration/elaborasi
- Construction/konstruksi
- Transition/transisi
- Inception
Tujuan utama adalah untuk ruang lingkup sistem secara memadai sebagai dasar untuk mengesahkan biaya awal dan anggaran. Dalam tahap ini kasus bisnis yang mencakup konteks bisnis, faktor-faktor kesuksesan (diharapkan pendapatan, pengenalan pasar, dll), dan prakiraan keuangan didirikan. Untuk melengkapi kasus isnis, kasus penggunaan dasar model, rencana proyek, penilaian risiko awal dan deskripsi proyek (inti persyaratan proyek, kendala dan fitur utama) yang dihasilkan. Setelah ini selesai, proyek ini diperiksa terhadap criteria sebagai berikut:
- Stakeholder persetujuan pada definisi lingkup dan biaya/jadwal perkiraan
- Pemahaman persyaratan sebagaimana dinuktikan oleh kesetiaan penggunaan utama kasus
- Kredibilitas dari biaya/jadwal memperkiraan, prioritas, resiko, dan proses pembangunan
- Kedalaman dan luasnya setiap arsitektur prototype yang dikembangkan
- Membangun dasar yang digunakan untuk membandingkan actual pengeluaran terhadap pengeluaran yang direncanakan
Jika proyek tidak lulus tonggak ini, yang disebut Tujuan Hidup Milestone, hal itu dapat dibatalkan atau dapat mengulangi fase ini setelah dirancang ulang untuk lebih memenuhi kriteria.
Peran Use Case pada Inception
- Menentukan Ruang lingkup proyek
- Membuat ‘Business Case’
- Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan
- Elaboration
Tujuan utama adalah untuk mengurangi resiko kunci item diidentifikasi dengan analisis hingga akhir fase ini. Fase perluasan dimana proyek mulai terbentuk. Dalam tahap ini masalah analisis domain dibuat dan proyek arsitektur mendapatkan bentuk dasarnya.
Fase ini harus lulus Arsitektur Siklus Hidup Milestine oleh kriteria sebagai berikut:
- Menggunakan model kasus dimana penggunaan-kasus dan para pelaku telah diidentifikasi dan sebagian besar kasus penggunaan deskripsi dikembangkan. Kasus penggunaan model ini harus menjadi 80% lengkap
- Penjelasan tentang arsitektur perangkat lunak dalam proses pengembangan sistem perangkat lunak
- Sebuah arsitektur executable yang menyadari penggunaan signifikan arsitektur kasus
- Kasus bisnis dan daftar resiko yang direvisi
- Sebuah rencana pengembangan untuk keseluruhan proyek
- Prototype yang terbukti mengurangi risiko teknis masing-masing diidentifikasi
Jika proyek tidak bisa lewat tonggak sejarah ini, masih ada waktu untuk itu dibatalkan atau didesain ualang. Setelah meninggalkan fase ini, proyek transisi ke dalam operasi beresiko tinggi dimana perubahan jauh lebih sulit dan merugikan ketika dibuat. Kunci domain analisis untuk perluasan adalah arsitektur sistem.
Peran Use Case pada Elaboration
- Menganalisa berbagai persyaratan dan resiko
- Menetapkan ‘base line’
- Merencanakan fase berikutnya yaitu construction
- Construction
Tujuan utama adalah untuk membangun sistem perangkat lunak. Pada tahap ini, focus utama adalah pada pengembangan komponen dan fitur lain dari sistem yang dirancang. Ini adalah tahap ketika sebagian besar terjadi pengkodean. Dalam proyek yang lebih besar, beberapa iterasikonstruksi bisa dikembangkan dalam upaya untuk membagi penggunaan dikelola kasus ke segmen yang menghasilkan prototype dibuktikan. Fase ini menghasilkan eksternal pertama peluncuran perangkat lunak. Kesimpulan yang ditandai oleh Initial Milestone Kemampuan Operasional.
Peran Use Case pada Construction
- Melakukan sederetan iterasi
- Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dantesting
- Transition
Tujuan utama adalah untuk ‘transisi’ sistem dari ke pengembanagn produksi, membuatnya tersedia untuk dan dipahami pleh pengguna akhir. Kegiatan ini meliputi pelatihan tahap akhir pengguna dan pengelola dan beta testing dari sistem untuk memvalidasi itu terhadap pengguna akhir harapan. Produk ini juga diperiksa terhadap tingkat kualitas ditetapkan dalam fase Inception.
Jika semua tujuan terpenuhi, maka Produk Milestone Release tercapai dan siklus pengembangan berakhir.
Peran Use Case pada Transition
- Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
- Dalam fase ini dilakukan:
- Beta dan performance testing
- Membuat rencana peluncuran produk ke komunitas pengguna
Ciri khas dari RUP dalam proses pengembangan perangkat lunak berbasis UML adalah adanya use case yang digunakan. Use case diagram digunakan untuk memodelkan bisnis proses berdasarkan pengguna sistem. Use case terdiri atas diagram use case dan actor. Actor merepresentasikan orang yang akan mengoperasikan atau orang yang berinteraksi dengan sistem aplikasi.
Use case merepresentasikan operasi-operasi yang dilakukan oleh actor. Use case digambarkan berbentuk elips dengan nama operasi di dalamnya. Actor yang melakukan operasi dihubungkan dengan garis lurus ke use case. Sehingga disini dapat disimpulkan bahwa use case mengadopsi Object Oriented Programming (OOP) karena memisahkan operasi-operasi maupun komponen yang terlibat di dalamnya ke dalam sebuah objek-objek yang berbeda.
2.) Critical Chain Project Management (CCPM)
adalah suatu metode penjadwalan baru yang dapat menjadi suatu alternatif baru sebagai solusi dari permasalahan tersebut. Sebenarnya CCPM tidak semata-mata melakukan penjadwalan proyek seperti yang dilakukan oleh CPM / PERT tetapi juga melakukan pendekatan manajemen. Semua ini bisa ditempuh dengan cara menghilangkan multitasking, student syndrome, parkinsons law serta memberi buffer di waktu akhir proyek. Penelitian ini bertujuan untuk menerapkan metode CCPM tersebut.
Contoh penerapan metodelogi ini bisa dilihat pada proyek The Grove Apartement, Retail and Mediawalk Jakarta yang tengah berjalan. Penjadwalan awal proyek menggunakan metode penjadwalan tradisional berupa gantt chart yang kemudian dibreakdown lebih detai ldan lengkap dengan hubungan antar aktivitasnya ke dalam bentuk CPM (Critical Path Method), dan kemudian akan dibandingkan dengan hasil dari penjadwalan CCPM yang telah menghilangkan multitasking, menghilangkan safety time pada tiap aktivitas dan memberi buffer dalam pengerjaannya. Selanjutnya perhitungan dengan metode penjadwalan CPM (Critical Path Method) dan CCPM (Critical Chain Project Management) akan dibandingkan menurut segi waktu dan segi biayanya. Dari hasil penelitian ini didapatkan durasi waktu dengan menggunakan metode penjadwalan CCPM adalah 304 hari. Sedangkan pada CPM didapatkan durasi 389 hari. Dari segi biaya, CCPM mampu menghemat biaya sedikitnya 2,1 milyar rupiah. Ini berarti metode penjadwalan CCPM lebih menguntungkan untuk diterapkan di proyek ini dari pada penjadwalan CPM
adalah suatu metode penjadwalan baru yang dapat menjadi suatu alternatif baru sebagai solusi dari permasalahan tersebut. Sebenarnya CCPM tidak semata-mata melakukan penjadwalan proyek seperti yang dilakukan oleh CPM / PERT tetapi juga melakukan pendekatan manajemen. Semua ini bisa ditempuh dengan cara menghilangkan multitasking, student syndrome, parkinsons law serta memberi buffer di waktu akhir proyek. Penelitian ini bertujuan untuk menerapkan metode CCPM tersebut.
Contoh penerapan metodelogi ini bisa dilihat pada proyek The Grove Apartement, Retail and Mediawalk Jakarta yang tengah berjalan. Penjadwalan awal proyek menggunakan metode penjadwalan tradisional berupa gantt chart yang kemudian dibreakdown lebih detai ldan lengkap dengan hubungan antar aktivitasnya ke dalam bentuk CPM (Critical Path Method), dan kemudian akan dibandingkan dengan hasil dari penjadwalan CCPM yang telah menghilangkan multitasking, menghilangkan safety time pada tiap aktivitas dan memberi buffer dalam pengerjaannya. Selanjutnya perhitungan dengan metode penjadwalan CPM (Critical Path Method) dan CCPM (Critical Chain Project Management) akan dibandingkan menurut segi waktu dan segi biayanya. Dari hasil penelitian ini didapatkan durasi waktu dengan menggunakan metode penjadwalan CCPM adalah 304 hari. Sedangkan pada CPM didapatkan durasi 389 hari. Dari segi biaya, CCPM mampu menghemat biaya sedikitnya 2,1 milyar rupiah. Ini berarti metode penjadwalan CCPM lebih menguntungkan untuk diterapkan di proyek ini dari pada penjadwalan CPM
