Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014
ISBN: 978-602-70467-0-2
PERBANDINGAN METODOLOGY KLASIK DAN AGILE DALAM PENGEMBANGAN SISTEM INFORMASI Fathiah1, Zulaida Rahmi2, Hayi Nukman 3 Prodi Teknik Informatika STMIK U’Budiyah Jl. Alue Naga Desa Tibang, Banda Aceh E-mail:
[email protected] 3 Magister Teknologi Informasi Universitas Gadjah Mada Jalan Grafika No. 2 Yogyakarta E-mail:
[email protected] 1,2
Abstrak Perkembangan teknologi informasi dan komunikasi yang sangat pesat ini cukup berpengaruh Ada banyak metode pengembangan perangkat lunak yang bisa kita gunakan dalam mengembangkan perangkat lunak. Banyaknya metode-metode yang ada terkadang meninggalkan permasalahan tersendiri bagi para pengem- bang, metode mana yang sebaiknya ia pilih demi mendap- atkan solusi yang paling baik dan dengan biaya pengem- bangan yang seminimal mungkin. Metode-metode ini tentunya memiliki kelebihan dan kekurangan sendiri, se- hingga perlu studi yang lebih lanjut mengenai bagaimana melakukan pemilihan metode yang baik dalam mengem- bangkan perangkat lunak ini. Banyak aspek yang bisa di- jadikan pertimbangan untuk memilih metode yang tepat, seperti biaya, sumber daya, waktu dan lainnya Kata kunci: pengembangan, perangkat lunak, biaya, sumber dana, waktu 1. PENDAHULUAN Pengembangan perangkat lunak telah menjadi bagian dari kehidupan modern saat ini semenjak lebih dari 50 tahun yang lalu. Pada awalnya, pengembangan perangkat lu- nak dibuat tanpa adanya banyak perencanaan yang spesi- fik. Seiring berkembangnya kebutuhan perangkat lunak, kebutuhan perancangan dan desain system pun menjadi se- buah kebutuhan. Terutama untuk system-system yang be- sar, yang lebih sulit untuk dibuat dan memiliki fitur-fitur yang kompleks. Berbagai metodologi pun mulai digunakan untuk memudahkan pengembang dalam mengembangkan systemnya. Banyak pilihan metode yang bisa kita gunakan dalam pengembangan sistem seperti Waterfall, spiral, proto- typing, RAD (Rapid Application Development), Scrum, Extreme Programming (XP), Bandung Bondowoso serta masih banyak lagi yang lainnya. Masingmasing metode ini memiliki kelebihan dan kekurangan sendiri-sendiri. Se- hingga terkadang membutuhkan studi khusus untuk menentukan metode mana yang sebaiknya akan kita gunakan dalam mengembangkan sebuah perangkat lunak, terlebih sebuah sistem informasi.
Banyak aspek yang bisa dijadikan acuan dalam pe- nentuan ini, misalkan seperti ukuran sistem, jumlah tim (SDM), resiko pengembangan, budget (dana), schedule (waktu) serta beberapa aspek lainnya. Ketepatan pemili- han metode tentunya akan sangat menguntungkan bagi de- veloper, terutama untuk penghematan cost baik cost waktu, cost resource maupun SDM. Dalam paper ini, kami akan mencoba untuk membandingkan dua metode pengemban- gan perangkat lunak yang cukup populer yakni metode Wa- terfall dan metode Agile dari beberapa aspek yang telah kami jabarkan di atas. 2.METODE KLASIK Metode pengembangan perangkat lunak (Software De- velopment Methodology) atau metode pengembangan sis- tem mengacu pada kerangka yang digunakan untuk membuat struktur, rencana, dan kontrol dari proses pengemban- gan sebuah sistem (khususnya sistem informasi)[2]. Dalam kata lain dapat dikatakan juga sebagai sebuah pendekatan yang digunakan oleh organisasi atau sebuah tim dalam mengembangkan perangkat lunak. Ada banyak metode-metode pengembangan perangkat lunak yang ada saat
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014 ini. Beberapa diantaranya merupakan metode dasar (klasik) yakni seperti metode Waterfall, Spi- ral dan Prototyping. Selain ketiga metode tersebut, telah banyak juga pengembangan metode-metode klasik lainnya seperti RAD, Incremental, V-Shaped model serta beberapa metode lainnya. 2.1Waterfall M o d e l Yakni sebuah desain proses yang sequensial (beruru- tan) yang dalam progressnya terlihat seperti aliran air terjun (waterfall) dari proses perancangan konsep, inisialisasi project, alanisis, desain, pembuatan system (coding), test- ing, produksi/implementasi dan perawatan (maintenance). Beberapa prinsip utama dari model ini yakni[2]: 1. Project dibagi-bagi dalam beberapa fase yang saling berurutan. 2. Penekanan pada perencanaan, jadwal (schedule), deadline, budget, dan implementasi keseluruhan sis- tem sekaligus. 3. Kontrol yang ketat dalam siklus hidup project dengan menggunakan bantuan dokumentasi tertulis. Kelebihan dari metode ini yakni: 1. Mudah dimengerti, mudah digunakan, 2. Requirement dari sistem bersifat stabil, 3. Baik dalam manajemen kontrol, 4. Bekerja dengan baik ketika kualitas lebih diutamakan dibandingkan dengan biaya dan jadwal (deadline).
Gambar 1. Metode Klasik Selain kelebihan-kelebihan di atas, model Waterfall ini memiliki kekurangan yang sangat banyak. Dikarenakan sangat banyak
ISBN: 978-602-70467-0-2
tim yang telah mengimplementasikan projectnya dengan menggunakan model ini. Beberapa diantara kekurangannya itu yakni: 1. Semua kebutuhan sistem harus diketahui terlebih dahulu, 2. Penenyahan dari setiap fase ke fase lainnya dapat dikatakan statis (tidak fleksible). 3. Dapat memberikan kesan palsu dari progresnya. 4. Tidak menunjukkan menunjukkan prinsif ”Problem- Solving” dalam Pengembangan Perangkat Lunak dikarenakan fase yang harus berurut. 5. Integrasi sekaligus di akhir sistem. 6. Customer hanya memiliki sedikit kesempatan untuk melihat dan mereview sistem (yakni di akhir project). 7. Resiko sangat tinggi, karena testing hanya dilakukan pada setiap akhir fase, bahkan tidak jarang testing hanya dilakukan di akhir-akhir project. 8. Membutuhkan waktu yang cukup lama (walaupun pro- jectnya tidak terlalu besar). 9. Perubahan requirement dapat merubah keseluruhan proses yang telah dilaksanakan. 2.2Prototyping Yakni sebuah pendekatan pengembangan dalam sebuah aktifitas pengembangan perangkat lunak untuk pembuatan prototype, misalnya berupa produk belum jadi dari perangkat lunak yang dikembangkan. Beberapa prinsip utamanya yakni: 1. Tidak berdiri sendiri, serig digabungkan dengan metode lainnya seperti Incremental, Spiral atau RAD. 2. Berusaha untuk mengurangi resiko project dengan memecahkannya kedalam sub-sub project yang lebih kecil yang memungkinkan untuk memudahkan perubahan. 3. User terlibat dalam proses, sehingga memungkinkan sistem yang sesuai dengan permintaan user. 4. Mock-ups berukuran kecil dari sistem dengan peruba- han berlanjut hingga sesuai dengan kebutuhan dari user. 5. Pengembangan lebih lanjut dengan mengembangkan prototype. Metode ini memiliki banyak keuntungan bagi developer, karena pada metode ini customer dan user system terli- bat secara
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014 langsung dalam pengembangan. Kelebihan dari metode ini yakni: 1. User dapat melihat secara langsung perkembangan system seiring dengan permintaannya, 2. Developer belajar langsung mengenai kebutuhan sistem dari customer/user, 3. Hasil produk yang lebih akurat (lebih sesuai dengan permintaan user), 4. Desain sistem lebih fleksibel, 5. Iteraktif dengan adanya simulasi prototype, 6. Untuk pengembangan lebih lanjut (jika terjadi peruba- han), developer hanya perlu mengubah prototype, 7. Jika customer sudah ”puas”, prototype dibuat menjadi system secara sempurna untuk dijadikan ’Final Prod- uct’. Sedangkan kekurangannya adalah: 1. Proses bisa jadi berlanjut terus menerus tanpa henti(mengikuti keinginan customer), 2. Bisa jadi customer malah menginginkan prototype sys- tem dikirim, 3. Reputasi yang buruk sebagai sebuah metode yang bersifat ”Quick-and-Dirty”. 4. Kemungkinan perawatan secara keseluruhan bisa saja terabaikan. 5. Pengembangan yang berlebihan untuk prototype. 2.3Spiral Model Spiral adalah proses pengembangan perangkat lu- nak yang menggabungkan antara elemen waterfall model dengan prototyping dalam setiap tahap, dalam upaya untuk menggabungkan keuntungan dari konsep topdown dan bottom-up. Model ini pertama kali dikenalkan pada tahun 1988 oleh Barry Boehm. Beberapa prinsip utama model ini yakni: 1. Fokus pada penilaian resiko dan minimalisasi resiko project dengan memecah project menjadi beberapa bagian. 2. Setiap perjalanan siklus spiral selalu melalui empat kuadran utama yakni: (1) menentukan objective atau tujuan, alternative-alternative dan batasan dalam it- erasi tersebut; (2) evaluasi alternativealternative, iden- tifikasi resiko dan penyelesaiannya; (3) pengembangan (develop) dan persiapan untuk pengajuan dari iterasi tersebut; dan (4) perencanaan untuk iterasi berikutnya. 3. Permulaan setiap siklus identifikasi stakeholder dan kondisi akhir, serta review dari setiap siklus.
ISBN: 978-602-70467-0-2
Kelebihan dari model ini yakni: 1 User dapat melihat sistem lebih awal dengan adanya rapid prototyping tools, 2 Fungsi-fungsi yang memiliki resiko tinggi dipriori- taskan lebih utama, 3 Desain sistem tidak perlu perfect 4 Mendapat respon yang lebih cepat dari user, 5 Perhitungan biaya dilakukan setiap saat. Sedangkan kelemahan dari model Spiral ini yakni: 1. Rumit, membutuhkan manajemen yang penuh perha- tian dan berpengalaman untuk bisa melakukannya. 2. Beresiko besar jika tidak sesuai dengan budget atau schedule. 3. Penggunaan waktu untuk melakukan evaluasi resiko terlalu besar. 4. Spiral (siklus) munkin bisa berlanjut tanpa batas. 5. Bisa sangat sulit untuk mendefinisikan tujuan dan pencapaian yang menujjukkan kesiapan untuk melan- jutkan menuju ke iterasi berikutnya. 6. Model ini hanya bekerja dengan baik pada project yang berukuran besar dan memiliki waktu pengerjaan yang panjang juga. 2.4Iterative dan Incremental Model Selain ketiga metode basik tersebut, ada beberapa metode lainnya yang merupakan pengembangan dari ketiga metode tersebut. salah satunya yakni metode Iterative dan Incremental Model. Iterative dan Incremental Model adalah sebuah model yang dibuat untuk menanggulangi kelema- han dari metode waterfall. Model ini dimulai dengan in- isialisasi perencanaan dan diakhiri dengan deployment atau produksi dengan sebuah lingkaran iterasi diantara peren- canaan dan deployment. Gambar 2 berikut dapat menjelaskan bagaimana siklus dari model ini.
Gambar 2. Iterative dan Incremental
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014 3. AGILE SDLC Agile software development (sering disebut ”ag- ile”)adalah kumpulan dari metodemetode pengembangan perangkat lunak yang berbasis pada Iterative dan In- cremental Model. Agile membawakan perubahan dari metode-metode kelas berat seperti waterfall dan Spiral. Agile adalah metode pengembangan perangkat lunak yang ringan, yang memungkinkan tim untuk mengembangkan perangkat lunak yang memiliki reequirement yang samar-samar dan mudah berubah dengan cepat.
Gambar 3. Agile Development Agile memiliki beberapa prinsip utama yang membedakannya dengan metode-metode klasik yang telah dijelaskan di atas. Prinsipprinsip ini telah dikenalkan dalam Agile manifesto sejak tahun 2001 lalu. Prinsipprinsip ini yakni: 1. Lebih cepat dalam merilis perangkat lunak secara terus menerus, 2. Pengiriman perangkat lunak sesering mungkin, 3. Dapat dengan mudah menerima perubahan require- ment, 4. Kebutuhan komunikasi harian antara customer dengan pengembang, 5. Kebutuhan komunikasi secara langsung antara cus- tomer dengan pengembang,
ISBN: 978-602-70467-0-2
6. Project dibangun antar tim, 7. Kepercayaan dan support terhadap tim, 8. Tim bebas mengorganisasikan dirinya sendiri, 9. Tim bebas bekerja dalam kecepatan yang bisa dipertahankan,Tim bebas mereview tingkat keberhasilan dan kegagalan mereka, 10.Sesederhana mungkin dalam desain dan implementasi, 11.Berusaha untuk keunggulan dalam desain teknis dan implementasinya. 3.1Kelebihan dan Kekurangan Agile (Scrum dan XP) Sebelum kita membahas tentang kelebihan Agile, mari kita coba list beberapa alasan utama kenapa sebuah project sering mengalami kegagalan. Alasan pertama yakni sedik- itnya keterlibatan user atau customer dalam proyek. Dalam beberapa kasus yang menggunakan metode pengembangan waterfall, user hanya terlibat pada fase analisis dan testing saja. Sehingga, kebanyaka user terkadang menerima begitu saja hasil yang diberikan oleh developer dengan sedikit sekali testing terhadap perangkat lunaknya. Alasan kedua yakni requirement yang ’buruk’. Beberapa hal yang munkin perlu kita jadikan catatan bahwasanya mustahil untuk mengumpulkan requirement di awalawal project dan semua requirement yang telah berhasil dikumpulkan tidak bisa dijamin untuk tidak berubah. Alasan lain yang menyebabkan buruknya requirement adalah karena user atau customer kadang tidak tahu apa yang mereka butuhkan. Alasan ketiga yakni schedule atau jadwal yang tidak realistis. Kadang jadwal tidak disepakati dari pihak-pihak yang terlibat dalam pengembangan, seperti tim yang men- ganalisa project terkadang memutuskan schedul project akan selesai dalam waktu tertentu yang terkadang menjadi beban bagi tim yang mengembangkan perangkat lunaknya. (tim developer). Tim developer terkadang tidak memiliki cukup waktu untuk mengembangkan perangkat lunak sehingga kadang membuat keterlambatan dalam penyerahan perangkat lunak yang jadi. Alasan keempat yakni sedikitnya testing.
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014 Pada banyak metode klasik, testing dilakukan di akhir-akhir fase, sehingga sangat sedikit testing yang dilakukan. Sedikitnya testing ini bisa mngakibatkan kemungkinan ditemukannya bug dan perbaikan dalam system sangatlah kecil. Hal ini mungkin menguntungkan bagi Developer, akan tetapi bisa berakibat buruk pada masa perawatan system setelah sys- tem diproduksi. Alasan kelima yakni minimnya adaptasi dengan perubahan requirement. Terkadang rencana bisa berubah di tengah jalan, rencana yang tadinya seharusnya lurus bisa jadi berliku-liku seiring dengan berubahnya permintaan cus tomer. Apa yang seharunya dikerjakan nanti belakangan, terkadang ditemukan penyelesaiannya terlebih dahulu. Serta masih banyak lagi alasan-alasan lainnya yang ser ing membuat sebuah project mengalami kegagalan. Apa hubungannya dengan Agile. Secara teori Agile dapat menanggulangi masalah-masalah ini berdasarkan dari prinsip-prinsip agile di atas. Beberapa keunggulan metode ini adalah: 1. Proses Iterative dan Incremental, 2. Requirement dapat berubah sewaktu-waktu, 3. Pelacakan requirement dengan melihat Backlog produk, 4. Keterlibatan user secara aktif, 5. Rilis yang lebih cepat dan berkala, fungsi dirilis setiap akhir iterasi. 6. Testing dilakukan setiap saat, Seperti metode-metode lainnya, Agile bukanlah metode yang sempurna. Agile memiliki kelemahan-kelemahan yang tidak kalah banyaknya dengan metode-metode klasik yang telah kami jelaskan di atas. Beberapa kelemahannya ini antara lain: 1. Agile jarang dipraktekkan secara langsung, 2. Interksi dengan customers yang berlebihan, 3. Agile sulid diimplementasikan dalam proyek yang berskala besar, 4. Membutuhkan manajemen tim yang terlatih 5. Lemah dalam perencanaan arsitektur, Scrum dan Extreme Programming 6. Keterbatasan waktu dalam perencanaan proyek 7. Serta beberapa kelemahan lainnya 3.2. Beberapa Metode Agile Seperti telah dijelaskan di atas, Agile merupakan sekumpulan metode-metode pengembangan perangkat lunak yang
ISBN: 978-602-70467-0-2
dikembangkan untuk menyelesaikan permasalahan-permasalahan yang ditemukan pada metode- metode klasik. Beberapa metode yang termasuk ke dalam metode agile yakni: 1. 2. 3. 4. 5. 6. 7.
Crystal (Light, Clear, Orange, dll) DSDM, Lean, Kanban, Rational Unifield Process (RUP), Scrum, Extreme Programming (XP) dan lainnya
Gambar 4. Agile Development Method Pada paper ini, kami tidak akan menjelaskan secara detail mengenai metodemetode di atas. Karena secara prisip memiliki kelebihan dan kekurangan yang hampir sama, akan tetapi memiliki sisi keunikannya sendiri-sendiri. Namun, diantara metode-meteode tersebut Scrum dan XP adalah metode yang paling populer (lihat Gambar 4). 4. BEBERAPA PERBANDINGAN Telah kami jelaskan secara singkat mengenai beberapa metode-metode pengembangan perangkat lunak yang populer saat ini. Kemudian manakah metode yang paling baik Berdasar State of Agile Survey 2010, The State of Agile Development untuk mengembangkan Sistem Informasi atau Perangkat Lunak pada umumnya? Untuk menjawab pertanyaan terse- but kami mencoba mengumpulkan beberapa fokus utama sebagai bahan perbandingan untuk menentukan manakah metode yang terbaik yakni Konsep dan Efisiensi. 4.1.Perbedaan Konsep Hampir semua metode memiliki konsep yang berbeda- beda. Ada yang sederhana sehingga sangat mudah di- mengerti seperti
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014
ISBN: 978-602-70467-0-2
metode waterfall. Ada juga yang sangat rumit seperti sebagian besar metode-metode yang termasuk dalam metode Agile.
4.1.1Planing dan Analisis Sistem Tahap analysis adalah tahap dimana kita menganalisa apa yang akan kita buat dari system, kenapa kita membuat system, bagaimana system akan dibuat dan bagaimana uru- tan (prioritas) pembuatan system yang akan dilakukan. Pada metode-metode klasik, tahap analisis dilakukan sete- lah inisialisasi proyek. Dimana pada tahap ini semua kebutuhan system dikumpulkan dari user baik dari user story maupun SRS yang telah disediakan oleh pemilik proyek (customer). Pada metode-metode klasik, sitem analis berusaha sekuat mungkin untuk menganalisa proyek se- belum dilanjutkan ke fase berikutnya. Sehingga terkadang hasil dari fase ini yang berupa SRS atau kebutuhan system biasanya bersifat statis. Tidak jauh berbeda pula pada metode Agile, tahap anal- ysis ini dilakukan di awalawal project. Pada Agile, besar kemungkinan hasil dari tahap analysis ini mengalami perubahan bergantung dari Kebutuhan customer. Karena mus- tahil untuk mengumpulkan semua requirement pada awal- awal proyek. Tidak jarang analisis dilakukan pada setiap iterasi, namun analisis yang dilakukan disini lebih spesifik ke fungsi tertentu saja. 4.1.2. Timeline Timeline termasuk menjadi pertimbangan untuk memilih metode. Pada metode klasik, lebih cenderung digunakan pada proyekproyek yang memiliki timeline cukup panjang (lebih dari 6 bulan). Sedangkan pada metode Agile, cukup fleksible jika digunakan pada proyek-proyek kecil yang memiliki timeline singkat. Pada metode klasik, rilis produk dilakukan pada akhir masa proyek. Dengan pola seperti ini, terkadang respon (feedback) dari user dan penemuan bug menjadi terlambat karena terkadang proyek telah memasuki fase perawatan baru terkadang bug ditemukan. produk dilakukan secara berkala. Dimana rilis tidak dilakukan secara langsung berupa program jadi, akan tetapi bertahap.
Gambar 5 . Timeline Metode Agile 4.1.3. Analisis Resiko Beberapa metode dikatakan memiliki resiko yang cukup tinggi dalam kondisi tertentu, misalkan ketika user tidak mengetahui dengan jelas apa yang ia butuhkan atau kon- disi ketika sumber daya yang dibutuhkan ternyata kurang. Metode klasik seperti waterfall memiliki resiko yang lebih besar pada kondisi dimana user tidak mengetahui apa yang ia butuhkan. Ketidak tahuan user tentang apa yang dibutuhkan pasar dan apa yang mereka inginkan terkadang membuat requirement dari sistem berubah-ubah. Atau ketika ide baru atau kebutuhan baru dari user bertambah atau bahkan berubah setelah user menggunakan system. Tentunya pada kondisi sepeti ini pemilihan metode waterfall bukanlah pilihan yang bijak karena akan membuat rencana yang tadinya telah direncanakan bisa berubah drastis. Pada kondisi seperti ini metode-metode agile lebih menjanjikan bagi anda. Sedangkan pada kondisi tertentu dimana para anggota tim adalah orang-orang baru yang belum terlatih atau apa- bila proyek yang akan dikerjakan adalah proyek upgrade dari system lama ke system baru tanpa harus merubah fungsi dalam system, tentunya akan menjadi ”gambling” jika menggunakan metode-metode agile. Metode-metode agile juga bukanlah menjadi pilihan yang bijak jika user lebih mementingkan kualitas dibandingkan dengan biaya dan waktu.
Gambar 6. Traditional Timeline
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014 4.1.4. Komposisi Tim Komposisi tim juga sangat memungkinkan untuk men- jadi pertimbangan dalam memilih metode. Jika anda memi- liki tim yang kecil (kurang dari 6 orang) mungkin akan san- gat sulit bagi anda untuk menggunakan komposisi tim yang komplit, atau mungkin bisa jadi anda membutuhkan para ahli dari luar untuk membuat agar tim anda komplit dan ten- tunya ini akan menambah cost produksi system.
Gambar 7. Komposisi Tim dalam Agile Pada metode-metode klasik, komposisi tim cukup kom- plit yakni tim analysis, tim desain system, tim developer dan tim tester (atau juga tim produksi). Komposisi seperti ini tentunya membutuhkan SDM yang cukup banyak un- tuk mengisi masing-masing tim. Sedangkan pada agile, kedudukan anggota tim dalam tim bersifat blur[8], dikare- nakan semua tim terlibat pada tahap development secara langsung. Untuk perusahaan bersekala kecil hingga menen- gah, komposisi tim seperti ini sangat menguntungkan, karena tim analis, desain, developer dan tester dapat bebraur langsung dalam pengembangan. Sehingga memungkinkan untuk menemukan kelemahan dan bug lebih awal sebelum rilis dilakukan. 4.1.5.Konstruksi System (Development Phase) Tahap Development atau implementasi atau tahap Cod- ing menjadi bagian terpenting dalam proses pengemban- gan perangkat lunak. Rencana tanpa implementasi menan-
ISBN: 978-602-70467-0-2
dakan kegagalan rencana tersebut. Pada tahap ini, semua rencana, rancangan, desain dan semua hal yang dirancang dalam tahap-tahap sebelumnya diimplementasikan. Pada metode klasik, implementasi dilakukan dilakukan secara keseluruhan dan hasil dari tahap ini berupa pro- duk perangkat lunak yang siap rilis (berada pada fase fi- nal). Pada tahap ini tim developer memiliki peran paling utama, sedangkan tim analisis dan tim desain system hanya melakukan kontrol untuk menjamin SRS dan desain telah diimplementasikan dengan baik oleh tim developer. Sedangkan pada metode-metode agile, implementasi di- lakukan secara berkala. Dimana setiap setelah rilis fitur, tim terlebih dahulu menganalisa kebutuhan untuk fitur yang akan dikembangkan berikutnya, kemudian mendesainnya agar fitur tersebut dapat dibuat atau dikembangkan pada system. 4.2. Efisiensi Efisiensi yang dimaksud disini adalah efisiensi penggu- naan sumber daya, waktu dan cost lainnya dalam project. Beberapa hal yang menjadi pertimbangan kami disini yakni Ukuran tim (SDM), budget (biaya) dan waktu. 4.2.1. Ukuran Tim Ukuran tim atau ukuran perusahaan (developer) dapat menjadi pertimbangan penting dalam memilih metode. Di atas telah kami jelaskan singkat mengenai komposisi tim dalam kedua metode tersebut. Nah, dari komposisi terse- but kita dapat menarik kesimpulan bahwa metode-metode klasik membutuhkan ukuran tim yang lebih besar diband- ingkan dengan metode-metode agile. Metode klasik seperti waterfall lebih cenderung untuk digunakan dalam tim yang ukurannya medium hingga besar (lebih dari 80 orang). Sedangkan metode-metode agile sangat efisien jika digu- nakan dalam ukuran tim yang kecil.
Gambar 8. Agile pada perusahaan
Prosiding SNIKOM 2014. Banda Aceh, 24 Mei 2014 4.2.2. Budget Biaya tentunya menjadi kendala utama dalam pengem- bangan system. System yang besar dan berkualitas baik ten- tunya membutuhkan biaya yang tidak sedikit untuk membu- atnya. Tidak jarang terkadang suatu proyek terhenti dikare- nakan kekurangan biaya, atau biaya yang diberikan oleh user atau customer tidak sebanding dengan tingkat kesuli- tan proyek. Kesalahan pemilihan metode juga berpengaruh terhadap kegagalan ini. Seperti yang telah kita ketahui, metode-metode klasik memakan waktu yang lebih lama dibandingkan dengan metode-metode agile. Semakin lama suatu proyek berjalan maka akan semakin banyak juga bi- aya yang harus dikeluarkan untuk proyek tersebut.
Gambar 9. Waktu dan Biaya (Time and Cost) 4.2.3. Waktu Waktu yang dimaksud disini yakni lama pelaksanaan proyek. Di atas telah kami terangkan sedikit mengenai waktu, dimana waktu ini sangat berpengaruh terhadap besarnya biaya yang harus dikeluarkan untuk proyek terse- but. Waktu berbanding lurus dengan budget atau biaya (lihat gambar 9). Metode-metode klasik memakan waktu yang lebih banyak dibandingkan dengan metodemetode agile. Akan tetapi kualitas yang dihasilkan sebanding dengan waktu pengerjaannya. Sedangkan pada metode agile, adanya prin- sip ”frequent delivery” atau rilis berkala terkadang mem- buat proyek terkesan terburu-buru dan jaminan kualitas secara keseluruhan tidak terlalu diperhatikan. 5. KESIMPULAN ”Jadi, manakah metode yang paling baik?” mungkin ini adalah pertanyaan yang kurang tepat –hidup (proyek) kadang jauh
ISBN: 978-602-70467-0-2
lebih rumit dari yang kita perkirakan. Semua metode-metode yang ada jika ditempatkan pada proyek yang tepat pasti akan menghasilkan sebuah produk yang berkualitas dan bersaing. Sebaliknya jika ditempatkan pada proyek yang salah karena kesalahan alalisa proyek, bisa jadi akan memakan biaya waktu dan uang yang jauh lebih besar dari yang diperkirakan. Kebijakan manajemen proyek dalam memilih metode dapat memberikan solusi yang lebih baik dan murah. Banyak aspek yang bisa dijadikan sebagai pertimbangan untuk memilih metode ini. Diantaranya seperti yang telah kami jabarkan di atas yakni dari sisi planign dan analisa system, timeline, resiko, komposisi tim, ukuran tim, bud- get, waktu serta masih banyak lagi aspek lainnya yang tidak dapat kami jabarkan secara rinci dalam paper ini. DAFTAR PUSTAKA A. G. Spiral model advantages and disadvantages. Oct 2010. [4] S. Govindaraj. Introduction to agile methods. slideshare, Cedar Point Consulting (CPC). Before you make the leap to agile - ten weakness of agile. 2011. Center for Medicare and Medicaid Services. Selecting a development approach. 2008. 2009. D. Leffingwell. Agile Software Requirements: Lean Require- ments Practices for Teams, Programs, and the Enterprise. Agile Development Series. Addison-Wesley, Upper Saddle River, NJ, 2011. J. Rasmusson. The Agile Samurai How Agile Masters Deliver Great Software. The Pragmatic Bookshelf, Raleigh, North Carolina Dallas, Texas, 2010. N. Jain. Agile is the new waterfall. agile?faqs, www.slideshare.net/nashjain/agile-is-thenew-waterfall, April 2009. V. One. State of agile survey 2010. Version One, www.versionone.com, 2010.
