Anda di halaman 1dari 16

1.

Unified Process
Unified Process (UP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perangkat lunak. Dalam kondisi apa UP dapat digunakan ? UP tepat digunakan dalam kondisi : Pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada UML (Unified Modeling Language) Mempunyai waktu pengembangan yang panjang Dikembangkan pada perangkat lunak sebagai sarana interaksi antara pengguna dan perangkat keras Mempunyai tim programmer yang cukup banyak Pengembangan dan perubahan perangkat lunak berdasarkan kebutuhan user RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat dilihat bahwa UP 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 atau beberapa iterasi. 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. Dimensi ini terdiri atas Inception,

Gambar 1. Arsitektur Unified Process

1. Fase-fase dalam Unified Process


Berdasarkan pada Gambar 1 di atas, menjelaskan mengenai fase-fase pada termasuk ke dalam dimensi pertama dari UP : a. Inception/insepsi Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user, dan melakukan perancangan awal perangkat lunak (perancangan arsitektural dan use case). Pada akhir tahap ini, prototipe perangkat lunak versi Alpha harus sudah dirilis. Kegiatan yang dilakukan pada tahap ini diantaranya : o Menentukan Ruang lingkup proyek Ruang lingkup proyek meliputi, tata cara untuk menentukan waktu proyek dimulai, perencanaan lingkup proyek yang akan dikerjakan, pendefinisian ruang lingkup proyek, verifikasi proyek serta kontrol atas perubahan yang mungkin terjadi saat proyek tersebut dimulai. Tujuan utama adalah untuk ruang lingkup sistem secara memadai sebagai dasar untuk mengesahkan biaya awal dan anggaran. o Membuat Business Case Business Case adalah alat yang mendukung perencanaan dan pengambilan keputusantermasuk keputusan tentang apakah yang akan dibeli, produk apa yang akan dibawa ke pasar, proyek apa yang akan di danai, dan vendor mana yang akan dipilih, atau kapan proyek tersebut dilaksanakan. Business Case umumnya dirancang untuk menjawab pertanyaan seperti di atas tentang konsekuensi dari suatu tindakan atau keputusan. Dalam tahap ini kasus bisnis yang mencakup konteks bisnis, faktor-faktor kesuksesan Unified Process yang

(diharapkan pendapatan, pengenalan pasar, dll), dan prakiraan keuangan didirikan. Untuk melengkapi kasus bisnis, kasus penggunaan dasar model, rencana proyek, penilaian risiko awal dan deskripsi proyek (inti persyaratan proyek, kendala dan fitur utama) yang dihasilkan o Menjawab pertanyaan apakah yang dikerjakan dapat menciptakan good business sense sehingga proyek dapat dilanjutkan Sebuah kasus bisnis yang baik juga mengidentifikasi faktor kesuksesan dan kontinjensi yang harus dikelola untuk menargetkan tingkat, untuk mencapai hasil yang diharapkan. Dan, kasus ini juga harus mengidentifikasi risiko - faktor yang tidak dapat dikendalikan atau dikelola, tetapi yang dapat menyebabkan hasil yang berbeda untuk muncul. b. Elaboration/elaborasi

Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikasikan fitur perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak. 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 Kegiatan yang dilakukan pada tahap ini diantaranya : o Menganalisa berbagai persyaratan dan resiko Di dalam sebuah proyek, terdapat beberapa persyaratan-persyaratan yang harus dipenuhi agar suatu proyek tersebut dapat terlaksana dengan baik. Selain itu melakukan analisa terhadap resiko juga diperlukan agar pada saat resiko tersebut terjadi, sudah ada persiapan untuk menanggulangi resiko-resiko yang akan terjadi. o Menetapkan base line Baseline adalah sebuah copy dari suatu project. Kita dapat membandingkan antara baseline dengan kondisi yang sekarang untuk mengevaluasi progress. Sebelum kita melakukan proses dating dari sebuah schedule, kita harus terlebih dahulu membuat sebuah baseline. o Merencanakan fase berikutnya yaitu construction Merupakan titik awal perancangan dan pengembangan testing dan dapat dipakai untuk menganalisa iterasi. c. Construction/konstruksi Pengimplementasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Tujuan utama adalah untuk membangun sistem perangkat lunak. Pada tahap ini, fokus 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 iterasi

konstruksi bisa dikembangkan dalam aya untuk membagi penggunaan dikelola kasus ke segmen yang menghasilkan prototype dibuktikan. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi perangkat lunak. Kegiatan yang dilakukan pada tahap ini diantaranya : o Melakukan sederetan iterasi Melakukan serangkaian kegiatan dan tugas, dengan sumber daya yang ditetapkan, mengandung ketergantungan tugas, untuk iterasi. Biasanya terdapat 2 rencana iterasi yang aktif pada setiap waktu yang sama, yaitu : a. Rencana iterasi yang saat ini digunakan untuk melacak kemajuan dalam iterasi yang sedang berlangsung. b. Rencana iterasi yang selanjutnya adalah rencana yang digunakan untuk merencanakan iterasi selanjutnya. rencana ini di siapkan untuk menghadapi akhir dari iterasi saat ini. o Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing d. Transition/transisi Instalasi , deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini. Tujuan utama adalah untuk transisi sistem dari ke pengembangan produksi, membuatnya tersedia untuk dan dipahami oleh 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. Kegiatan yang dilakukan pada tahap ini diantaranya : o Membuat apa yang sudah dimodelkan menjadi suatu produk jadi o Dalam fase ini dilakukan: Beta dan performance testing

Melakukan testing pada produk yang sudah jadi untuk mengetahui apakah masih terdapat bug atau tidak, apabila produk tersebut masih terdapat bug maka feedback akan dikirim ke developer untuk dilakukan pengecekan dan patching pada bug tersebut. Membuat dokumentasi tambahan seperti : training, user guides dan sales kit.

Membuat rencana peluncuran produk ke komunitas pengguna. 2. Kelebihan dan Kekurangan dalam Unified Proccess Keuntungan Pengembangan Perangkat Lunak UP : Ada beberapa keuntungan dengan mengunakan UP di antaranya :

a. Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim. b. Menyediakan petunjuk bagaimana menggunakan UML secara efektif. c. Mendukung proses pengulangan dalam pengembangan software. d. Memungkinkan adanya penambahan-penambahan pada proses. e. Memungkinkan untuk secara sistematis mengontrol perubahan- perubahan yang terjadi pada software selama proses pengembangannya. f. Memungkinkan untuk menjalankan test case dengan menggunakan Test Manager Tool Kekurangan Pengembangan Perangkat Lunak UP : Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada UML (Unified Modeling Language)

3.

Contoh Penerapan Metodologi Pengembangan Perangkat Lunak Unified Proccess

Pengembangan Perangkat Lunak dengan Menggunakan UP (Contoh Kasus) Perangkat lunak, atau piranti lunak adalah program komputer yang berfungsi sebagai sarana interaksi antara pengguna dan perangkat keras. Perangkat lunak dapat juga dikatakan sebagai penterjemah perintah-perintah yang dijalankan pengguna computer untuk diteruskan ke atau diproses oleh perangkat keras. Perangkat lunak ini dibagi menjadi 3 tingkatan: tingkatan program aplikasi (application program misalnya Microsoft Office), tingkatan sistem operasi (operating system misalnya Microsoft Windows), dan tingkatan bahasa pemrograman (yang dibagi lagi atas bahasa pemrograman tingkat tinggi seperti Pascal dan bahasa pemrograman tingkat rendah yaitu bahasa rakitan). Perangkat lunak adalah program komputer yang isi instruksinya dapat diubah dengan mudah. Perangkat lunak umumnya digunakan untuk mengontrol perangkat keras (yang sering disebut sebagai device driver), melakukan proses perhitungan, berinteraksi dengan perangkat lunak yang lebih mendasar lainnya (seperti sistem operasi, dan bahasa pemrograman), dan lain-lain.

2. XP (Extreme Programming) Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak. Dalam Kondisi apa XP dapat digunakan ? XP tepat digunakan saat kondisi :

Keperluan berubah dengan cepat Resiko tinggi dan ada proyek dengan tantangan yang baru Tim programmer sedikit, yaitu antara 2-10 orang Mampu mengotomatiskan tes Ada peran serta pelanggan secara langsung

Tujuan XP Tujuan utama XP adalah menurunkan biaya dari adanya perubahan software. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel terhadap perubahan. Variabel XP Terdapat 4 variabel XP, yaitu antara lain : 1. Cost (biaya) Dengan meningkatkan biaya, kita bisa menciptakan program yang lebih baik. Sebaliknya mengurangi biaya untuk proyek tidak akan menyelesaikan masalah customer. Tetapi, biaya yang tiak terbatas juga akan menimbulkan kerusakan.

2. Time (waktu) Dengan meningkatkan waktu makan kita akan mampu menciptakan program yang berkualitas dan dengan feature-feature yang lebih banyak.Akan tetapi waktu yang berlebihan tidak baik, karena dapat merusak terhadap diri sendiri. Waktu yang sedikit juga tidak baik karena kualitas yang dihasilkan akan jauh dari yang diharapkan. 3. Quality (mutu) Mutu merupakan suatu variabel pengendali yang sangat mengerikan karena merupakan suatu hal yang sangat diperhatikan oleh konsumen. 4. Scope (feature) Scope merupakan varibel primer. Jika kita mengurangi Scope,maka kita bisa mengurangi biaya dan meningkatkan kualitas. Kunci utama XP (XP Value) Menurut penggagas dari metode XP, Kent Beck mendefinisikan lima kunci utama dari XP, yaitu : 1. Communication XP memfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programmer yang biasanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programmer lain dalam menuliskan kode program. 2. Courege Para anggota tim dan penanggungjawab pengembangan perangkat lunakharus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar. Untuk dapat melakukan sesuatu dengan penuh integritas, terlebih dahulu para anggota tim memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya. 3. Simplicity Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan metode yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP. 4. Feedback Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan.Dengarkan selalu pendapat rekan yang lain. Dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan. 5. Quality Work Semua nilai di atas berujung pada sebuah kondisi dimana kita melakukan pekerjaan dengan berkualitas. Denagn proses yang berkualitas maka akan muncul pula implikasi perangkat lunak yang berkualitas sebagai hasil akhir.

Prinsip utama XP Dalam penerapannya, Extreme Programming memiliki lima prinsip utama, yaitu: 1. Rapid Feedback Menurut ilmu psikologi, waktu antara sebuah aksi dengan feedbacknya sangat penting untuk dipelajari. Dalam sebuah proyek XP, developer memperoleh feedback sesegera mungkin, menginterpretasikannya, lalu mengambil inti sarinya dan meletakkannya ke dalam system. Feedback dari pelanggan terhitung harian, bukan bulanan, dan feedback dari developer terhitung menitan, bukan mingguan! 2. Assume Simplicity Hanya mendesain untuk masalah saat ini dan menghemat waktu 98% dari masalah tersebut dan hanya menekuni sekitar 2% untuk bagian yang sulit. XP berencana untuk masa depan sehingga desainnya bias di-reuse, lakukan pekerjaan yang penting, dan percayalah bahwa untuk kekompleksitasan bias ditambahkan kemudian. 3. Incremental Change Pemecahan problem yaitu dengan bagian-bagian kecil perubahan saja. Jadi perubahan-perubahan yang terjadi pada XP melalui tahap-tahap kecil dan waktu yang singkat. 4. Embracing Change Mencari dan menyediakan terlebih dahulu sebanyak mungkin pilihan ketika menyelesaikan masalah yang begitu menekan. 5. Quality Work Setiap orang suka mengerjakan pekerjaan yang bagus dan layak dan kualitas yang dimaksud di sini adalah kualitas yang sempurna dan kualitas yang sempurna secara ekstrim. Karena tanpa kualitas kita tidak akan suka melakukan pekerjaan tersebut, hasilnya tidak akan sempurna dan proyeknya akan jatuh berantakan. Aspek Dasar XP Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:

Gambar 2. Teknik-teknik dalam XP

1. The Planning Game Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi game karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut. 2. Small Releases Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem. 3. Metaphor Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor. 4. Simple Design Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari.

5. Refactoring Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya. 6. Testing XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis test code design. 7. Pair Programming Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. 8. Collective Ownership Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat

diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya. 9. Coding Standards Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program. 10. Continous Integration Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi. 11. 40-hours Week Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan. 12. On-Site Customer Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.

3. AGILE MODELING Salah satu ciri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam pembangunan software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll. Selain itu Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development: 1. kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus 2. menerima perubahan kebutuhan, sekalipun diakhir pengembangan. 3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan. 4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung 5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek. 6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien 7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek 8. Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan 9. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile 10. Kesederhanaan penting 11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri 12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya: 1. kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek. 2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan. 3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

Faktor Manusia pada Agile Process Model Kunci faktor manusia pada model ini adalah proses didasari pada kebutuhan orang dan tim bukan sebaliknya, Untuk dapat sukses menerapkan model proses ini, pada faktor manusia ada beberapa kunci penting: 1. kompetensi: ketrampilan dalam membangun dan pengetahuan tentang proses membangun 2. Fokus: memiliki fokus yang sama sekalipun peran dalam tim berbeda 3. Kolaborasi : kerja sama dengan klien, anggota tim dan manajer. 4. Kemampuan ambil keputusan : tim pembangun memiliki otonomi dalam pengambilan keputusan terkait teknis dan proyek 5. Kemampuan fuzzy problem-solving: mampu menyelesaikan memilah masalah yang penting untuk dipecahkan segera atau nanti. 6. Saling percaya dan hormat: kekompakan tim yang didukung oleh rasa percaya dan saling menghargai satu sama lain. 7. Manajemen diri: tim mengatur diri untuk selesaikan proyek, mengatur proses untuk disesuaikan dengan lingkungannya, tim menjadwal dirinya untuk menyerahkan hasil. Agile Process Model Berikut ini adalah model-model proses yang termasuk agile process model : 1. XP(Extreme Programming) 2. ADAPTIVE SOFTWARE DEVELOPMENT (ASD) 3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 4. SCRUM 5. AGILE MODELING

4. SCRUM Scrum adalah sebuah pendekatan tangkas untuk pengembangan perangkat lunak. Scrum merupakan suatu kerangka kerja. Jadi, bukannya menyediakan deskripsi rinci tentang bagaimana segala sesuatu yang harus dilakukan pada proyek seperti diserahkan kepada tim pengembangan perangkat lunak pada umumnya. Hal ini dilakukan supaya tim akan tahu bagaimana cara terbaik untuk memecahkan masalah yang mereka disajikan. Inilah sebabnya mengapa, misalnya, rapat perencanaan sprint digambarkan dalam bentuk hasil yang diinginkan (komitmen untuk mengatur fitur yang akan dikembangkan di sprint berikutnya), bukan definisi Tugas, kriteria Validasi, dll seperti yang akan disediakan dalam metodologi yang lain. Scrum bergantung pada pengorganisasian-diri, tim lintas fungsional. Tim scrum adalah mengorganisir diri dalam bentuk tidak ada pemimpin tim secara keseluruhan yang memutuskan mana orang yang akan melakukan tugas atau bagaimana suatu masalah akan dipecahkan. Mereka adalah isu-isu yang ditentukan oleh tim secara keseluruhan. Tim ini lintas fungsional sehingga setiap orang perlu untuk mengambil fitur dari ide untuk diimplementasi. Tim-tim pengembangan scrum yang didukung oleh dua orang tertentu: Scrum Master dan pemilik produk (product owner). Scrum Master dapat dianggap sebagai pelatih bagi tim, membantu anggota tim menggunakan kerangka Scrum untuk tampil di tingkat tertinggi. Pemilik produk mewakili bisnis, pelanggan atau pengguna dan memandu tim ke arah pegembangan produk yang tepat. proyek Scrum membuat kemajuan dalam serangkaian sprint, yang timeboxed iterasi tidak lebih dari sebulan panjang. Pada awal sprint, anggota tim berkomitmen untuk memberikan beberapa nomor fitur yang terdaftar di product backlog proyek. Pada akhir sprint, fitur ini dilakukan mereka diimplementasikan, diuji, dan diintegrasikan ke dalam produk berkembang atau sistem. Pada akhir sprint tinjauan sprint dilakukan selama tim menunjukkan fungsi baru kepada pemilik produk dan pemangku kepentingan lain yang memberikan umpan balik yang dapat mempengaruhi sprint berikutnya. Penjelasan tambahan : a) Diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an b) Pengembangan berikutnya dilakukan oleh Schwaber dan Beedle c) Scrum memiliki prinsip: Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain Proses dapat beradaptasi terhadap perubahan teknis dan

bisnis proses menghasilkan beberapa software increment Pembangunan dan orang yang membangun dibagi dalam tim yang kecil Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan d) Aktifitas Scrum : Backlog, Sprints, Scrum Meetings, Demo

Gambar 4. Proses Scrum e) Aktifitas Backlog : Backlog adalah daftar kebutuhan yang jadi prioritas klien. Daftar dapat bertambah. f) Aktifitas Sprints: unit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30hari). Selama proses ini berlangsung backlog tidak ada penambahan. g) Aktifitas Scrum Meeting: pertemuan 15 menit perhari untuk evaluasi apa yang dikerjakan, hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya. h) Aktifitas Demo : penyerahan software increment ke klien didemonstrasikan dan dievaluasi.

16