Perbandingan Metodology Klasik dan Agile

Perbandingan Metodology Klasik dan Agile Dalam Pengembangan Sistem Informasi Fathiah Magister Teknologi Informasi Universitas Gadjah Mada Jalan Graka No. 2 Yogyakarta fathia um@yahoo.com Hayi Nukman Magister Teknologi Informasi Universitas Gadjah Mada Jalan Graka No. 2 Yogyakarta hayi.nkm@gmail.com

Abstract 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 mendapatkan solusi yang paling baik dan dengan biaya pengembangan yang seminimal mungkin. Metode-metode ini tentunya memiliki kelebihan dan kekurangan sendiri, sehingga perlu studi yang lebih lanjut mengenai bagaimana melakukan pemilihan metode yang baik dalam mengembangkan perangkat lunak ini. Banyak aspek yang bisa dijadikan pertimbangan untuk memilih metode yang tepat, seperti biaya, sumber daya, waktu dan lainnya. 1. Pendahuluan Pengembangan perangkat lunak telah menjadi bagian dari kehidupan modern saat ini semenjak lebih dari 50 tahun yang lalu. Pada awalnya, pengembangan perangkat lunak dibuat tanpa adanya banyak perencanaan yang spesik. Seiring berkembangnya kebutuhan perangkat lunak,kebutuhan perancangan dan desain system pun menjadi sebuah kebutuhan. Terutama untuk system-system yang besar, yang lebih sulit untuk dibuat dan memiliki tur-tur 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, prototyping, RAD (Rapid Application Development), Scrum,Extreme Programming (XP), Bandung Bondowoso serta masih banyak lagi yang lainnya. Masing-masing metode ini memiliki kelebihan dan kekurangan sendiri-sendiri. Sehingga 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 penentuan ini, misalkan seperti ukuran sistem, jumlah tim (SDM), resiko pengembangan, budget (dana), schedule (waktu) serta beberapa aspek lainnya. Ketepatan pemilihan metode tentunya akan sangat menguntungkan bagi developer, terutama untuk penghematan cost baik cost waktu, cost resource maupun SDM. Dalam paper ini, kami akan mencoba untuk membandingkan dua metode pengembangan 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 Development Methodology) atau metode pengembangan sistem mengacu pada kerangka yang digunakan untuk membuat struktur, rencana, dan kontrol dari proses pengembangan 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 ini. Beberapa diantaranya merupakan metode dasar (klasik) yakni seperti metode Waterfall, Spiral 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.1. Waterfall Model Yakni sebuah desain proses yang sequensial (berurutan) yang dalam progressnya terlihat seperti aliran air ter-jun (waterfall) dari proses perancangan konsep, inisialisasi project, alanisis, desain, pembuatan system (coding), testing, produksi/implementasi dan perawatan (maintenance). Beberapa prinsip utama dari model ini yakni[2]: Project dibagi-bagi dalam beberapa fase yang saling berurutan. Penekanan pada perencanaan, jadwal (schedule), deadline, budget, dan implementasi keseluruhan sistem sekaligus. Kontrol yang ketat dalam siklus hidup project dengan menggunakan bantuan dokumentasi tertulis. Kelebihan dari metode ini yakni: Mudah dimengerti, mudah digunakan, Requirement dari sistem bersifat stabil, Baik dalam manajemen kontrol, Bekerja dengan baik ketika kualitas lebih diutamakan dibandingkan dengan biaya dan jadwal (deadline).

Gambar 1. Tiga metode klasik dalam pengembangan perangkat lunak (Waterfall, Prototyping dan Spiral)

Selain kelebihan-kelebihan di atas, model Waterfall ini memiliki kekurangan yang sangat banyak. Dikarenakan sangat banyak tim yang telah mengimplementasikan projectnya dengan menggunakan model ini. Beberapa diantara kekurangannya itu yakni: Semua kebutuhan sistem harus diketahui terlebih dahulu, Penenyahan dari setiap fase ke fase lainnya dapat dikatakan statis (tidak eksible) Dapat memberikan kesan palsu dari progresnya. Tidak menunjukkan menunjukkan prinsif ProblemSolving dalam Pengembangan Perangkat Lunak dikarenakan fase yang harus berurut. Integrasi sekaligus di akhir sistem. Customer hanya memiliki sedikit kesempatan untuk melihat dan mereview sistem (yakni di akhir project). Resiko sangat tinggi, karena testing hanya dilakukan pada setiap akhir fase, bahkan tidak jarang testing hanya dilakukan di akhir-akhir project. Membutuhkan waktu yang cukup lama (walaupun projectnya tidak terlalu besar). Perubahan requirement dapat merubah keseluruhan proses yang telah dilaksanakan. 2.2. Prototyping Yakni sebuah pendekatan pengembangan dalam sebuah aktitas pengembangan perangkat lunak untuk pembuatan prototype, misalnya berupa produk belum jadi dari peragkat lunak yang dikembangkan. Beberapa prinsip utamanya yakni[2]: Tidak berdiri sendiri, serig digabungkan dengan metode lainnya seperti Incremental, Spiral atau RAD. Berusaha untuk mengurangi resiko project dengan memecahkannya kedalam sub-sub project yang lebih kecil yang memungkinkan untuk memudahkan perubahan. User terlibat dalam proses, sehingga memungkinkan sistem yang sesuai dengan permintaan user. Mock-ups berukuran kecil dari sistem dengan perubahan berlanjut hingga sesuai dengan kebutuhan dari user. Pengembangan lebih lanjut dengan mengembangkan prototype. Metode ini memiliki banyak keuntungan bagi developer, karena pada metode ini customer dan user system terlibat secara langsung dalam pengembangan. Kelebihan dari metode ini yakni: User dapat melihat secara langsung perkembangan system seiring dengan permintaannya, Developer belajar langsung mengenai kebutuhan sistem dari customer/user, Hasil produk yang lebih akurat (lebih sesuai dengan permintaan user), Desain sistem lebih eksibel, Iteraktif dengan adanya simulasi prototype, Untuk pengembangan lebih lanjut (jika terjadi perubahan), developer hanya perlu mengubah prototype, Jika customer sudah puas, prototype dibuat menjadi system secara sempurna untuk dijadikan Final Product. Sedangkan kekurangan-kekurangannya yakni: Proses bisa jadi berlanjut terus menerus tanpa henti (mengikuti keinginan customer), Bisa jadi customer malah menginginkan prototype system dikirim, Reputasi yang buruk sebagai sebuah metode yang bersifat Quick-and-Dirty.

 Kemungkinan perawatan secara keseluruhan bisa saja terabaikan. Pengembangan yang berlebihan untuk prototype. 2.3. Spiral Model Spiral adalah proses pengembangan perangkat lunak yang menggabungkan antara elemen waterfall model dengan prototyping dalam setiap tahap, dalam upaya untuk menggabungkan keuntungan dari konsep top-down dan bottom-up. Model ini pertama kali dikenalkan pada tahun 1988 oleh Barry Boehm. Beberapa prinsip utama model ini yakni: Fokus pada penilaian resiko dan minimalisasi resiko project dengan memecah project menjadi beberapa bagian Setiap perjalanan siklus spiral selalu melalui empat kuadran utama yakni: (1) menentukan objective atau tujuan, alternative-alternative dan batasan dalam iterasi tersebut; (2) evaluasi alternativealternative, identikasi resiko dan penyelesaiannya; (3) pengembangan (develop) dan persiapan untuk pengajuan dari iterasi tersebut; dan (4) perencanaan untuk iterasi berikutnya. Permulaan setiap siklus identikasi stakeholder dan kondisi akhir, serta review dari setiap siklus. Kelebihan dari model ini yakni: User dapat melihat sistem lebih awal dengan adanya rapid prototyping tools, Fungsi-fungsi yang memiliki resiko tinggi diprioritaskan lebih utama, Desain sistem tidak perlu perfect, Mendapat respon yang lebih cepat dari user, Perhitungan biaya dilakukan setiap saat. Sedangkan kelemahan dari model Spiral ini yakni: Rumit, membutuhkan manajemen yang penuh perhatian dan berpengalaman untuk bisa melakukannya. Beresiko besar jika tidak sesuai dengan budget atau schedule. Penggunaan waktu untuk melakukan evaluasi resiko terlalu besar. Spiral (siklus) munkin bisa berlanjut tanpa batas. Bisa sangat sulit untuk mendenisikan tujuan dan pencapaian yang menujjukkan kesiapan untuk melanjutkan menuju ke iterasi berikutnya. Model ini hanya bekerja dengan baik pada project yang berukuran besar dan memiliki waktu pengerjaan yang panjang juga.[3] 2.4. Iterative dan Incremental Model Selain ketiga metode basic 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 kelemahan dari metode waterfall. Model ini dimulai dengan inisialisasi perencanaan dan diakhiri dengan deployment atau produksi dengan sebuah lingkaran iterasi

diantara perencanaan dan deployment. Gambar 2 berikut dapat menjelaskan bagaimana siklus dari model ini. 3. Agile SDLC Agile software development (sering disebut agile)adalah kumpulan dari metode-metode pengembangan perangkat lunak yang berbasis pada Iterative dan Incremental Model. Agile membawakan perubahan dari model metode-metode kelas berat seperti waterfall dan Spiral Gambar 2. Iterative dan Incremental.

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. Prinsip-prinsip ini telah dikenalkan dalam Agile manifesto1 sejak tahun 2001 lalu. Prinsip-prinsip ini yakni: 1 www.agilemanifesto.org Lebih cepat dalam merilis perangkat lunak secara terus menerus, Pengiriman perangkat lunak sesering mungkin, Dapat dengan mudah menerima perubahan requirement, Kebutuhan komunikasi harian antara customer dengan pengembang, Kebutuhan komunikasi secara langsung antara customer dengan pengembang, Project dibangun antar tim, Kepercayaan dan support terhadap tim, Tim bebas mengorganisasikan dirinya sendiri, Tim bebas bekerja dalam kecepatan yang bisa dipertahankan, Tim bebas mereview tingkat keberhasilan dan kegagalan mereka,

 Sesederhana mungkin dalam desain dan implementasi, Berusaha untuk keunggulan dalam desain teknis dan implementasinya. 3.1. Kelebihan 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 sedikitnya 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 awal-awal 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 menganalisa 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. 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 system 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 customer. Apa yang seharunya dikerjakan nanti belakangan, terkadang ditemukan penyelesaiannya terlebih dahulu. Serta masih banyak lagi alasan-alasan lainnya yang sering 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 agile 2 dengan metode-metode lainnya yakni: Proses Iterative dan Incremental, Requirement dapat berubah sewaktu-waktu, Pelacakan requirement dengan melihat Backlog produk, Keterlibatan user secara aktif, Rilis yang lebih cepat dan berkala, fungsi dirilis setiap akhir iterasi. 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, Interksi dengan customers yang berlebihan, Agile sulid diimplementasikan dalam proyek yang berskala besar,

 Membutuhkan manajemen tim yang terlatih, Lemah dalam perencanaan arsitektur,2 Scrum dan Extreme Programming Keterbatasan waktu dalam perencanaan Proyek, Serta beberapa kelemahan lainnya. 3.2. Beberapa Metode Agile Seperti telah dijelaskan di atas, Agile merupakan sekumpulan metode-metode pengembangan perangkat lunak yang dikembangkan untuk menyelesaikan permasalahan-permasalahan yang ditemukan pada metodemetode klasik. Beberapa metode yang termasuk ke dalam metode agile yakni: Crystal (Light, Clear, Orange, dll) DSDM, Lean, Kanban, Rational Unield Process (RUP), Scrum, Extreme Programming (XP) dan lainnya Gambar 4. Agile Development Methode

Pada paper ini, kami tidak akan menjelaskan secara detail mengenai metode-metode 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)3. 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 3 Berdasar State of Agile Survey 2010, The State of Agile Developmentuntuk mengembangkan Sistem Informasi atau Perangkat Lunak pada umumnya? Untuk menjawab pertanyaan tersebut kami mencoba mengumpulkan beberapa fokus utama sebagai bahan perbandingan untuk menentukan manakah metode yang terbaik yakni Konsep dan Esiensi. 4.1. Perbedaan Konsep Hampir semua metode memiliki konsep yang berbeda beda. Ada yang sederhana sehingga sangat mudah dimengerti seperti metode waterfall. Ada juga yang sangat rumit seperti sebagian besar metode-metode yang termasuk dalam metode Agile.

4.1.1. Planing 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 urutan (prioritas) pembuatan system yang akan dilakukan[6]. Pada metode-metode klasik, tahap analisis dilakukan setelah 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 sebelum 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 sis ini dilakukan di awal-awal project. Pada Agile, besar kemungkinan hasil dari tahap analysis ini mengalami pe rubahan bergantung dari Kebutuhan customer. Karena mustahil untuk mengumpulkan semua requirement pada awalawal proyek. Tidak jarang analisis dilakukan pada setiap iterasi, namun analisis yang dilakukan disini lebih spesik ke fungsi tertentu saja. 4.1.2. Timeline Timeline termasuk menjadi pertimbangan untuk memilih metode. Pada metode klasik, lebih cenderung digunakan pada proyek-proyek yang memiliki timeline cukup panjang (lebih dari 6 bulan). Sedangkan pada metode Agile, cukup eksible 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[4]. Sedangkan untuk metode-metode Agile, rilis produk dilakukan secara berkala. Dimana rilis tidak dilakukan secara langsung berupa program jadi, akan tetapi bertahap Gambar 5. Timeline Metode Klasik

Gambar 6. Timeline Metode Agile

berdasar kesepakatan (biasanya per-fungsi). Dengan cara ini user dapat secara langsung mereview produk, sehingga bug (jika ada) dan feedback dari user bisa diperoleh lebih cepat. Dengan rilis berkala ini juga memungkinkan untuk developer mengalami perubahan pada program lebih cepat jika ada perubahan requirement dari user atau customer[4]. Timebox antar rilis biasanya antara 1-6 minggu.

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 kondisi 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[4]. Ketidak tahuan user tentang apa yang dibutuhkan pasar dan apa yang mereka inginkan terkadang membuat requirement dari sistem berubahubah. 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. 4.1.4. Komposisi Tim Komposisi tim juga sangat memungkinkan untuk menjadi pertimbangan dalam memilih metode. Jika anda memiliki tim yang kecil (kurang dari 6 orang) mungkin akan sangat sulit bagi anda untuk menggunakan komposisi tim yang komplit, atau mungkin bisa jadi anda membutuhkan parahli dari luar untuk membuat agar tim anda komplit dan tentunya ini akan menambah cost produksi system. Gambar 7. Komposisi Tim dalam Agile

Pada metode-metode klasik, komposisi tim cukup komplit yakni tim analysis, tim desain system, tim developer dan tim tester (atau juga tim produksi). Komposisi seperti ini tentunya membutuhkan SDM yang cukup banyak untuk mengisi masing-masing tim. Sedangkan pada agile, kedudukan anggota tim dalam tim bersifat blur[8], dikarenakan semua tim terlibat pada tahap development secara langsung. Untuk perusahaan bersekala kecil hingga menengah, komposisi tim seperti ini sangat menguntungkan, karena tim analis, desain, developer dan tester dapat bebaur 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 Coding menjadi bagian terpenting dalam proses pengembangan perangkat lunak. Rencana tanpa implementasi menandakan 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 produk perangkat lunak yang siap rilis (berada pada fase 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 dilakukan secara berkala. Dimana setiap setelah rilis tur, tim terlebih dahulu menganalisa kebutuhan untuk tur yang akan dikembangkan berikutnya, kemudian mendesainnya agar tur tersebut dapat dibuat atau dikembangkan pada system. 4.2. Esiensi Esiensi yang dimaksud disini adalah esiensi penggunaan 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 tersebut kita dapat menarik kesimpulan bahwa metodemetode klasik membutuhkan ukuran tim yang lebih besar dibandingkan dengan metode-metode agile. Metode klasik seperti waterfall lebih cenderung untuk digunakan dalam tim yang ukurannya medium hingga besar (lebih dari 80 orang)[7]. Sedangkan metode-metode agile sangat esien jika digunakan dalam ukuran tim yang kecil. Gambar 8. Agile pada perusahaan

4.2.2. Budget Biaya tentunya menjadi kendala utama dalam pengembangan system. System yang besar dan berkualitas baik tentunya membutuhkan biaya yang tidak sedikit untuk membuatnya. Tidak jarang terkadang suatu proyek terhenti dikarenakan kekurangan biaya, atau biaya yang diberikan olehuser atau customer tidak sebanding dengan tingkat kesulitan proyek. Kesalahan pemilihan metode juga berpengaruh terhadap kegagalan ini. Seperti yang telah kita ketahui, metodemetode klasik memakan waktu yang lebih lama dibandingkan dengan metode-metode agile. Semakin lama suatu proyek berjalan maka akan semakin banyak juga biaya 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 tersebut. Waktu berbanding lurus dengan budget atau biaya (lihat gambar 9)[5]. 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 prinsip frequent delivery atau rilis berkala terkadang membuat 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 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 jabarjkan di atas yakni dari sisi planign dan analisa system, timeline, resiko, komposisi tim, ukuran tim, budget, waktu serta masih banyak lagi aspek lainnya yang tidak dapat kami jabarkan secara rinci dalam paper ini.